Subject: Re: [Boost-build] allowing targets to fail
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-03-25 02:48:50
On 24.03.2017 18:14, Steven Watanabe via Boost-build wrote:
> On 03/24/2017 02:02 PM, Stefan Seefeld via Boost-build wrote:
>> On 24.03.2017 15:56, Steven Watanabe via Boost-build wrote:
>>> On 03/24/2017 01:00 PM, Stefan Seefeld via Boost-build wrote:
>>>> Consider for example a dependency graph where D depends on C depends on
>>>> B depends on A. A and B are ordinary (file) targets, but C and D are
>>>> 'test targets' (for example, C may compile a test, and D may run it).
>>>> How could I allow C or D to fail (i.e. tell b2 not to generate an error
>>>> message), but still record the error for a later report generation step
>>> I'm not quite sure I understand. If you don't want an
>>> error message, then where exactly is the error supposed to
>>> be recorded?
>> Somewhere internally, so I can capture it programmatically (and
>> post-process it in step E below, but without `b2` command itself to
>> report it to stdout / stderr.
> There isn't really a way. NOCARE is almost what you
> need, but its behavior for targets with updating
> actions isn't clearly specified. I think it's
> better just to let the targets fail. Boost.Build
> doesn't stop on errors by default, so I don't see
> that avoiding a failed exit status buys you much.
Can you elaborate on "not specified" a bit ? Or, would it be possible to
do specify it (and then adjust the implementation accordingly) ?
What effect does NOCARE have for dependent targets ? Will they be
skipped if a NOCARE target "fails" ?
I really do want to distinguish between build failures and test
failures, and would prefer a real solution rather than a work around in
the scripting layer.
>>>> In addition, how could I write another target E that should only be
>>>> run after all the others, but without depending on the tests having run
>>>> successfully ?
>>> Make E depend on a NOTFILE NOCARE target, which
>>> has a dependency on all the tests. In theory, I
>>> think this is supposed to work, but the implementation
>>> seems buggy. (When I tried it, E silently disappears)
>> Would that be a bug in the engine, or inside the boost.build jam /
>> python layer above it ?
> It's in the engine. I think it was a symptom
> of a different problem. When I reduce the test
> case to something basic, it seems to work. I've
> attached the sample script (run with b2 -f test.jam).
Thanks, I'll have a look.
-- ...ich hab' noch einen Koffer in Berlin...
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