|
Boost-Build : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-21 13:08:40
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? 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.
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?
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?
--Beman
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk