Re: [boost] tests.jam

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-13 17:20:08

----- Original Message -----
From: "Joerg Walter" <jhr.walter_at_[hidden]>
To: "David Abrahams" <david.abrahams_at_[hidden]>
Cc: <jamboost_at_[hidden]>
Sent: Sunday, January 13, 2002 11:24 AM
Subject: Re: [boost] tests.jam

> Hi David,
>
> you wrote:
>
> > 1. You too: time to use argument lists!
> >
> > 2. Why did you add a separate run-unit-test?
>
> This seemed to be necessary because of the differences in argument lists
and
> command line structure of unit-test and status/Jamfile tests.

There should be a way to unify them; the code is nearly (if not exactly)
identical. At worst, you can use a different action rule and invoke it
indirectly by passing its name to the common function. Jam code is hard
enough to maintain; we should eschew code duplication so as not to make it
harder.

> > run-test is the one that should
> > be invoked from the unit-test rule. The problem with the old unit-test
> > functionality is that when the execution returns a non-zero result code,
> the
> > build action for the executable fails, so Jam deletes it. The next time
> you
> > try to do a test, the exe needs to be rebuilt. That's why run-test
builds
> a
> > separate file that reflects the success of the test.
>
> Fixed for unit-test.

I was arguing for code unification, but as I said in the previous paragraph,
it doesn't look like we have it yet.

> > 3. It would probably be a good idea to leave the unit-test rule in
> > boost-base, and have it cause tests.jam to be included if it hasn't been
> > already (heck, maybe it's time to use the new module system?)
>
> Another idea is to include tests.jam in boost-base.jam.

I think we can afford to do that; reading .jam files takes no appreciable
time. If you don't do that, though, you should add some kind of include
guard so it only comes in once.

> What do you think?
> If that's a bad idea, I'll transfer unit-test back when it's working as
> intended.

Either way is fine.

> > 1. Maybe we shouldn't be checking for UNIX everywhere before propagating
> > gRUN_LD_LIBRARY_PATH:
> > a. It's messy, and can probably be avoided, since empty variables
will
> > usually have no effect
> > b. It might be needed or desired for Cygwin anyway
> > c. We can get rid of near-duplicate action blocks
>
> Agreed. Fixed this one, but tested only under Linux.
>
> > 2. I have the feeling that in some cases (especially the Unix cases)
we're
> > putting too much stuff in gRUN_PATH. I think we're putting stuff that NT
> > would need to find DLLs in gRUN_PATH, which just makes the final actions
> > needlessly large and complicated.
>
> Fixed, but tested only under Linux.

Removing the setting of RUN_LD_LIBRARY_PATH from Link-EXE looks like a
mistake. What if you build an EXE that depends on some built shared libs?

I think transmission of RUN_PATH and LD_LIBRARY_PATH ought to happen
unconditionally, regardless of platform, and LD_LIBRARY_PATH should always
contain only library path dependencies, while RUN_PATH contains only
executable path dependencies. When these things reach a point where they
must be interpreted (e.g. a testing rule), they should be combined on NT as
appropriate. That will make the code lots cleaner, don't you think?

> > 3. Instead of reconstituting PATH by saving the variable on startup,
> > extending it, and re-setting it, should we instead do something like:
> >
> > $(SHELL_SET)PATH=$(RUN_PATH)$(SHELL_EXISTING_PATH)
> >
> > where SHELL_EXISTING_PATH is ;%PATH% on NT and :$PATH on Unix?
>
> Wouldn't this imply even more attributes for the nodes of the dependency
> tree, i.e. $SHELL_EXISTING_PATH($(...)) and
> $SHELL_EXISTING_LD_LIBRARY_PATH($(...))? I tried it, but I'm not sure, if
> this is the better solution.

No, I'm sorry to have been unclear. $SHELL_EXISTING_PATH is meant to be a
global variable, sort of like $(SHELL_EXPORT). It's a simple way to avoid
manipulating the path imported from the environment. Then we have to worry
less about clobbering it by mistake and putting something bogus in the path,
plus the build actions become smaller and more readable. On Unix it would
contain the string "$PATH", on NT "%PATH%". Just a short string.

-Dave