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 assert functionality?
Is this test being run on all platforms whenever bjam is changed?
No. I plan to change regression tests to run those, however. - Volodya