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

[William Deegan]

Evan,

You make some good points.  
As I see it, there are 3 types of SCOns users:
1) open source building software for the world, should build in many different environments
2) Hobbyist/individual - Should build on my machine. don't care about any other
3) Commercial - It should build on all the machines at the company (and maybe at a partners), but the versions of the tools and the location of the tools needs to be tightly controlled such that a user's PATH doesn't cause the build system to pick up the "wrong" tool(s).

Even on #1 it may be reasonable/important to use the system install gcc vs another version the user has built as it may not work with other system installed libraries. (gcc's ABI does change from time to time).

For #1 though if it's important to just work, then the author should import the users PATH if it's reasonable to them.

-Bill
On Dec 28, 2012, at 7:32 PM, Evan Driscoll <driscoll at cs.wisc.edu> wrote:


> 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

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev