|
Boost-Build : |
Subject: Re: [Boost-build] allowing targets to fail
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-03-24 20:02:33
On 24.03.2017 15:56, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 03/24/2017 01:00 PM, Stefan Seefeld via Boost-build wrote:
>> the bjam C code presently allows for actions to fail if the "xfail" flag
>> is set. This means that actions are either expected to pass (default) or
>> fail (if the xfail flag is set). `b2` will report an error if it wasn't
>> able to rebuild any targets.
>>
>> How does that map to tests, which may pass or fail (at various stages of
>> the process) ? Is there a way to indicate to b2 that a (test) target may
>> fail to be built or be run ? And similarly, is it possible to still
>> collect the status of these tests so a proper test report can be generated ?
>>
>> 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.
>> 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 ?
Thanks,
Stefan
-- ...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