|
Boost-Build : |
Subject: Re: [Boost-build] allowing targets to fail
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-03-24 22:14:49
AMDG
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.
>>> 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).
In Christ,
Steven Watanabe
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