[Scons-dev] another test env issue, tool-finding

[Dirk Baechle]

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