On 12/20/2012 12:09 PM, William Deegan wrote: > On Dec 20, 2012, at 9:51 AM, "Managan, Rob" <manag...@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@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev