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

[Gary Oberbrunner]

On Sun, Dec 23, 2012 at 9:18 PM, Dirk Baechle <tshortik at gmx.de> wrote:


> 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.

>


I basically agree with this.  I'll do option 2 for the tar builder (make
the test code find it, and pass that into the env['ENV']).

The one thing that still bugs me a little is I feel like there's a
difference between a compiler, where different versions will give vastly
different results, and you really need to control them, and something like
LaTeX (especially) or tar, where I think users just want it to create their
PDF or .tgz file.  They might be more unsophisticated users of SCons, and
so trying harder to find the tool might make sense.  But given where we
are, and current design goals, I'm OK with option 2, both for the packaging
tool tests and Dirk's LaTeX test fixes (where needed).

Of course once we refactor tools and toolchains, it should be easy to have
tool-finding modes for both classes of users, (and in general, tools should
have tool-specific options) and we should aim for that.  And of course if
tools gave decent errors, a lot of these problems would go away.



> 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.

>


The packaging tool's exists() method already sort of does this, but since
exists() doesn't take an Environment it doesn't really meet your
requirements.  I agree this would be nice to have.

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20121224/c61a4713/attachment.htm>