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