We've been discussing whether the LaTeX tests should go to extra effort to
find LaTeX, or whether the base tool should do it. I just found another
similar case: on my Windows machine, test/FindSourceFiles.py fails because
the packaging tool can't find tar (it's in /cygwin/bin), so it doesn't
create a tar_bz packager -- so far that 's OK, but the test code only skips
the test if test.where_is('tar') fails. But that succeeds on my machine
because /cygwin/bin is in my path and that where_is looks in $PATH.
So here I think there are three options:
1: the packaging tool could try harder to find tar (look in cygwin, mingw,
etc.)
2: the test code, having found tar, could pass its path into the code
under test using env.AppendENVPath
3: the test code could just always skip the test on Windows.
I don't particularly like 3, because the test (and the packaging code)
*could* succeed there, and it'd be nice to exercise it.
I can easily make 2 work -- this is basically the path Dirk chose for
making the LaTeX tests pass if I remember correctly (or something like it).
But it does seem a little odd. Why should the tests be "smarter" than the
tool?
That leaves 1. But that has the problem that it introduces a certain
amount of randomness and "magic" into the tool -- if you happen to have
cygwin, and it's installed in a particular place, the tool will work. But
it won't be clear to users how to make it work between systems because it's
not explicit. The same with the LaTeX stuff; if it just looks around in
the filesystem it'll sometimes (usually?) work. But is that what we want?
Maybe (???) SCons needs a global tool-finding mode; if it's set to "try
harder" it looks in all the likely canonical places. Otherwise it behaves
as usual. On the other hand, setting env['ENV']['PATH'] =
os.environ('PATH') basically accomplishes the same thing (or similar).
Ideas?
--
Gary
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
