[Scons-dev] Extensions to the Tool subsystem...

[Evan Driscoll]

On 12/20/2012 12:09 PM, William Deegan wrote:

> On Dec 20, 2012, at 9:51 AM, "Managan, Rob" <managan1 at llnl.gov> wrote:

>> My question is where does Scons stand these days on the issue of paths and

>> not using the whole user environment by default?

> 

> From my perspective NOT propagating the users environment by default is an important feature of any sane build system.

> You want to have a repeatable build. ...

> 

> That said, there's always been a (documented) way for developers of build systems using SCons as their build tool to propagate the users environment if it's desirable for them.


I know this email was a bit ago but I thought I'd put in my two cents
anyway.

Take the Tar builder for instance. From my perspective, one of two
things has to be true for a sane build system: either it should be able
to figure out where that tool lives automatically even if it is located
in some crazy place (for instance, my main Windows desktop has Cygwin
installed to p:\programs\cygwin, and Latex is installed to
p:\programs\miktex), or there needs to be a STANDARD, CONSISTENT way for
me to tell SCons where it is located.

[Disclaimer before I continue: I don't think I've ever used Tar(), and
I'm not sure I've used the Latex tools on Windows, so it's possible
everything currently just works. I can't test it now. If so: great!]


On autodetection:

For some tools like 'tar', it's my opinion that the ONLY correct way to
autodetect where it is located is to look at the PATH environment
variable, and if you try any other approach (e.g. look for Cygwin or
Msys) then you have to provide a standard configuration option. For
instance, maybe I just want to download the gnuwin32 version which just
gives you a zip file you extract somewhere.

So if the tar tool basically looks through the invocation $PATH to find
the tar executable and, say, uses the full path to it if it's in some
weird location; that's fine. (One way of looking at this is that the
PATH variable provides a way

I'm not sure how many tools this applies too. Maybe it's just simple
things like 'tar', or maybe it's more complex stuff. I'm not sure.


On path selection:

You state that it's possible for the SConstruct writer to import the
environment -- but I think this is far from sufficient. What happens if
I want to build some piece of software where the writer DIDN'T do this?
If it uses .Tar() and my 'tar' is in some location it can't autodetect,
how can I fix it?

If the answer is "go edit SConstruct", I think that there's a lot of
work to be done. IMO, if you want to go this route, the 'tar' tool
should listen to some 'scons TAR=xxx' command line option.

Alternatively, there should be a standard, easily-findable place where I
can tell SCons "here's where my stuff is located!" (for instance to put
some function call at the top of SConstruct that says "add this to
env['ENV']['PATH'] for *all* environments you ever make"). It doesn't
have to be foolproof, just hard to get wrong.

Sure, maybe the author did things nicely and it's pretty easy to find
what to edit, but maybe it isn't. I could even see it being somewhat
obnoxious to find out what file even needs changed, let alone what line
and how to do it.


Evan