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

[William Deegan]

Greetings,


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


> I wanted to weigh in with a path related issue that came up in the LaTeX

> tools.

> 

> 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. Thus if a users environment can change the tools used by the build, you may end up (And I have) spending days trying to figure out why user A's build doesn't quite work the way User B's build does due to some bug in a specific version of the compiler..

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.



> 

> For Macs, the Latex tools were rarely on the default paths that Scons

> searched and therefore you had to create an Environment that included

> os.environ's path.  This was a real pain since most of the test/TEX/*

> files did not do thatŠ So what I came up with and is in the code base now

> is to add to the path the directories that the system adds to its path for

> installed features like Latex and X11. We did this because Mac OSX has a

> standard file/directory (/etc/paths and /etc/paths.d/*) that lists

> directories that get added to the system path.

> 

> Is there a similar set of paths on Windows that we should add to the

> default? Or is there a place to look for a path when initializing a

> specific tool that needs a given executable or set of executables?


Each tool (assuming it's installed by the tools standard windows installer) has a default install path.
If the user installs into a separate path, then in some (most?) cases (when the installer doesn't store the install info in the registry) it's o.k. for the build to fail to find the tool.
I think the main problem we have now is that we don't do a good job notifying the user when we fail to find a tool, especially important if it was explicitly requested.

I think this discussion actually has two parts:
1) Should SCons pull paths from the users environment when it is run by default? (I believe no)
2) Should the test infrastructure provide a way to specify alternative path in general, and for specific tools such that tests machines could have multiple versions/competing tools installed and get the test infrastructure to include/exclude them from a given test run. (I believe this may resolve your issue above)

-Bill


> 

> I think is one issue that needs work as we discuss tool initialization.

> 

> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

> Rob Managan                             email managan at llnl.gov

> LLNL                                             phone: 925-423-0903

> P.O. Box 808, L-095                   FAX:   925-422-3389

> Livermore, CA  94551-0808

> 

> 

> 

> 

> 

> On 12/20/12 9:09 AM, "Dirk Bächle" <tshortik at gmx.de> wrote:

> 

>> Hello developers,

>> 

>> based on my proposed changes to the current tests in src/test there has

>> been some discussion about how a Tool should work. Especially in

>> connection with the LaTeX Tool, questions like:

>> 

>>  - Do we want to have one "latex" Tool for all, or separate ones for

>> "miktex", "texlive"...?

>>  - Should a Tool try to find a "Miktex" installation in the current

>> system, or simply search for

>>    the "latex" executable while relying on a correct setup of the PATH

>> variable?

>> 

>> showed up.

>> 

> 

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

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