Re: [Boost-build] allowing targets to fail

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:
> 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.

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.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...