[Ns-developers] ns-3 source code style issues
gjcarneiro at gmail.com
Sat Oct 21 04:00:06 PDT 2006
On 10/21/06, mathieu lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
> On Fri, 2006-10-20 at 14:07 +0100, Gustavo Carneiro wrote:
> > OK, here's my hg branch: http://telecom.inescporto.pt/~gjc/hg/ns-3/
> > In this branch you'll find essentially two changes:
> > 1. hg diff -r 128:129 is "Make the build system honor the system
> > environment."
> I understand what you are proposing now: there are very good reasons why
> scons does not propagate env variables by default. The rationale is that
> you want to maximize the likelyhood of getting a clean sandbox and being
> able to reproduce the exact same build on multiple systems with
> different environments. So, we really do not want to propagate random
> env variables by default.
I have recently been discussing this in the SCons list and I thoroughly
disagree with this behaviour. The user should be in full control of his
environment. For example, what if I wanted to test compilation with another
compiler (say, test gcc 5.0 when it comes out) that I built myself and
installed into a different prefix (so as to not disturb the rest of my
system). Normally, I would change PATH to point at this compiler. But
SCons doesn't allow that by default.
Another point is, if and when you want a sandbox predictive behaviour, you
can do it in the shell script that invokes the build system. But this is
rare and should not be the default. And no other tool out there does this;
it is just evil.
I could go on and on about this, but it is pointless to argue. If it's
not clear to you why overriding the environment with hardcoded values is
wrong, there's nothing more I can say to convince you otherwise.
I do not know which variables gcccolor needs but you might find the
> existing support for cflags ldflags enough: look in the top-level BUILD
> - cflags: flags for the C compiler.
> Example: scons cflags="-O3 -ffast-math"
> - cxxflags: flags for the C++ compiler.
> Example: scons cxxflags="-O3 -ffast-math"
> - ldflags: flags for the linker:
> Example: scons ldflags="-L/foo -L/bar"
> Is this enough ?
If not, what do you need ?
We need at least to propagate the TERM environment variable.
If it is enough, it would be
> cool to add this somewhere in the wiki: "how to use gcccolor".
> > 2. hg diff -r 129:132 is "Make all Python sources PEP 8 compliant"
> > Change 2 is on top of 1; sorry about that.
> Being on top is no problem. What is a problem in this changeset is that
> it contains a lot of changes which have no relationship to the one you
> said you wanted (change 'foo ()' to 'foo()'). So, if you want me to pull
> a change from your repo, you need to provide a repo with a changeset
> which does not do this.
The composite change set 129:132 does what you want. I had already
noticed the mistakes and did extra commits to undo them, and that's why you
need more than one changeset for the desired effect. The command I listed
in 2 produces such a patch.
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."
More information about the Ns-developers