Greetings,

On Dec 20, 2012, at 9:51 AM, "Managan, Rob" <[email protected]> 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" <[email protected]> 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
> [email protected]
> http://two.pairlist.net/mailman/listinfo/scons-dev

_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev

Reply via email to