Re: [jamboost] Regression test: link-fail problem?

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-21 13:23:54

-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <jamboost_at_[hidden]>; <jamboost_at_[hidden]>
Sent: Wednesday, August 21, 2002 2:08 PM
Subject: Re: [jamboost] Regression test: link-fail problem?

> At 11:53 AM 8/21/2002, David Abrahams wrote:
> >From: "Beman Dawes" <bdawes_at_[hidden]>
> >
> >
> >> At 09:28 PM 7/8/2002, David Abrahams wrote:
> >>
> >> >This is exactly the sort of thing I was afraid would arise. AFAICT
> >> there's
> >> >no simple way to put this in the build system without making core
Jam
> >> >changes.
> >> >
> >> >The basic problem looks like this. Given a dependency chain:
> >> >
> >> >a->b->c->d->e
> >> >
> >> >when building "e" fails, you want something to happen with the
> >> >.test/.success/.failure files. These are associated with A.
However,
> >the
> >> >build system just stops working on "a" the instant any of its
> >> dependencies
> >> >fails to build.
> >>
> >> Ah. That is a nice explanation, and gives me a better understanding
of
> >what
> >> is happening.
> >
> >This explains exactly the behavior you last reported in
> >http://groups.yahoo.com/group/jamboost/message/1661
> >
> >> As long as a program scanning the output log and the residue left in
> the
> >> test directory can figure out where in the a->b->c->d->e chain a
> problem
> >> occurred, I may be able to deal with it.
> >
> >Was your assumption that this limitation could be dealt with incorrect?
>
> I guess so. I have no recollection of how I might have thought that was
> possible.
>
> In another thread, you said:
>
> > The unit-test rule is really not very sophisticated: it makes
> > the .exe target dependent on a successful run. Of course that
> > means that it gets removed if the run fails.
>
> Is there some reason you can't do this for the regression tests?

When you try to rebuild a bunch of tests, do you want it to work on
rebuilding tests which have no chance of succeeding because nothing has
changed since the last failure? That's the reason unit-test was deemed
inadequate in the first place.

> I'll
> settle for any clear indication at all a, b, c, and d have failed when e
> fails. It doesn't have to be the presence or absence of
> .test/.success/.failure files.

I could easily arrange for the .exe to be removed if any of its
dependencies fails, but that won't cause any of the residue files to be
touched. The scheme right now is that those files are not considered
targets in the build (they can't be, or they won't be updated when building
their dependencies fails).

> In the case where a is an .exe target, don't people complain when e fails
> and bjam leaves a there as if building it had succeeded?

Not so far, but that's easy to change.

> Or are you saying that a failure of e in a->b->c->d->e deletes a, b, c,
and
> d targets in some cases but not others, depending upon the exact target
> type?

The normal behavior is to remove a target when any of its direct build
actions fails. If I invoke the RMOLD rule on a target it will be removed
when any of its direct or indirect build actions fails. It wouldn't be a
good idea to do that for archives (static libs), for example because that
means all the work of archiving files would be thrown out as soon as a
compilation error occurred.

-Dave