From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-11-03 12:20:44
Robert Ramey wrote:
> I ran it from inside cmd.exe and got the same result.
> John Maddock wrote:
>> David Abrahams wrote:
>>>> I can try the the normal DOS-like shell or the cygwin shell if you
>>>> think that would make a difference.
>>> If you use a "windows bjam" (built from the cmd shell) you need to
>>> run it from inside cmd.
> hmmm ... yet another hidden variable.
> I built bjam from the tools/build directory - If I remember correctly
> and this was some time ago so that's another possible source.
>> I run the Windows build of bjam under cygwin all the time: and for
>> that matter to build and test my stuff under cygwin. You just have
>> to remember that when bjam shell's out it'll be using cmd.exe to
>> execute commands and
>> not cygwin.
> Do you visually inspect the bjam.log when you do this? Do
> you know for a fact that an "assert" wiill result in a "failed"
> test? If this behavior were occuring in your environmemnt,
> how would you know about it?
> I only discovered it when I found a couple of tests which
> only "failed" in release mode - which is never tested by default.
> Only when I went to investigate this did I discover that the
> there was a failed assertion that was in fact being marked "passed"
> Is there a test in the bjam test suite which verifys this?
No, because it's not bjam thing. The Boost.Build testsuite does
include test/regression.py test that tests that non-zero
return from a program is detected. It worked on windows a couple
of weeks ago, and nothing was changed in that department since
then. Can you reproduce this problem using a minimal testcase --
preferrably not using any of boost.serialization, or any non-standard
> Is this
> test being run on all platforms whenever bjam is changed?
No. I plan to change regression tests to run those, however.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk