Re: [boost] [Config] Macros for the absence of a full C++11 <memory> implementation

Subject: Re: [boost] [Config] Macros for the absence of a full C++11 <memory> implementation
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-02-17 11:22:55

AMDG

On 02/17/2014 01:48 AM, John Maddock wrote:
>> We could say that x.run passes iff
>> testing.capture-output is skipped
>> because a dependency failed or has
>> non-zero exit status.  But... this
>> will make a mess of the total pass/fail
>> counts and will fail badly with -q,
>> not to mention that it will cause the
>> test to pass if a library dependency
>> fails to build.
> 
> I realise this may not be possible, but a better rule would be a "not"
> rule: passes only if it's dependency failed.  But like you say, the
> total pass/fail count would presumably be messed up?
> 

That's annoying, but not really important.
Handling -q (stop on error) is much more
of a problem.

Actually, there is a way to handle this.
Unfortunately, it requires intrusive
changes to the toolsets.

compile.c++ x.obj x.run : x.cpp ;
link x.exe x.run : x.obj ;
capture-output x.run : x.exe ;
FAIL_EXPECTED x.run ;
NOCARE x.obj x.exe ;

By using x.run in all three rules, we cause
x.run to fail immediately when any of these
rules fails.  FAIL_EXPECTED then flips the
final status to pass.  Since x.obj and x.exe
might succeed or fail, we also say that it
doesn't matter whether they update successfully.

(Note that this will only work correctly
with a recent b2.  I think I fixed some
problems when using FAIL_EXPECTED with
multiple updating actions a few months ago)

In Christ,
Steven Watanabe