Hi Gary, Gary Oberbrunner wrote: > [...] > 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? >
I don't think this is odd, but natural in a way. If we want to make our tests run anywhere, they have to be very smart and robust. It's okay for a Tool to probe one or two default installation paths, but then the user is on his own. And if they chose to override the standard paths, they probably had a good reason for it. The user wants to build in his special environment, with the exact versions and paths he specifies. And that's what our Tools have to support in first place...and they already do. So, I don't see this as a contradiction and would support idea 2. There is one thing that we really need to add, and I think I listed it already in my Tool extension list. A method that "a priori" checks whether a Tool could be loaded within a given Environment. This method could then be used instead of the current where_is() or detect() calls throughout the tests. It would prevent us from executing tests that are bound to fail because the required application is only found in the global PATH, which doesn't get propagated to the actual build Environment. Just my 2 cents, and a "Merry Christmas" to everyone, Dirk _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
