https://svn.boost.org/trac10/ticket/5514 <p> Hello, </p> <p> I would like to report a problem I have noticed using Boost.Build combined with the Boost Unit Testing Framework. The problem manifests when using the <strong>run</strong> rule to execute unit tests, in a fashion similar to what is shown on this <a class="ext-link" href="http://www.alittlemadness.com/2009/12/10/boost-test-xml-reports-with-boost-build/"><span class="icon">​</span>tutorial</a>. </p> <p> The problem is that, on Windows platforms, when one or more tests fail, the bjam return code is 0, while it is 1 on Linux. The propagation of this erroneous return value has been traced to the following code snippet, from <em>tools/build/v2/tools/testing.jam</em>: </p> <pre class="wiki">actions capture-output bind INPUT_FILES output-file { $(PATH_SETUP) $(LAUNCHER) "$(&gt;)" $(ARGS) "$(INPUT_FILES)" &gt; "$(output-file)" 2&gt;&amp;1 $(.SET_STATUS) $(.RUN_OUTPUT_NL) &gt;&gt; "$(output-file)" echo EXIT STATUS: $(.STATUS) &gt;&gt; "$(output-file)" if $(.STATUS_0) $(.CP) "$(output-file)" "$(&lt;)" $(.ENDIF) $(.SHELL_SET)verbose=$(.VERBOSE_TEST) if $(.STATUS_NOT_0) $(.SHELL_SET)verbose=1 $(.ENDIF) if $(.VERBOSE) echo ====== BEGIN OUTPUT ====== $(.CATENATE) "$(output-file)" echo ====== END OUTPUT ====== $(.ENDIF) exit $(.STATUS) } </pre><p> The problem comes from the exit command, which, called from a Windows batch file, closes the whole shell instead of the batch file, causing <strong>%ERRORLEVEL%</strong> to be reset to 0. The proper way to call <em>exit</em> from a batch file is the following: </p> <pre class="wiki">exit /B $(.STATUS) </pre><p> For more information, type <em>exit /?</em> in a Windows command shell. For now, the error level propagated is always zero, which is not consistent with the Linux implementation. A diff attempting at correcting this particular problem was submitted with this post. </p> <hr /> <p> Also, this is a good opportunity to discuss what return value bjam should return when the build is over. It makes sense to return 0 for a successful build, and 1 if some targets could not be built. </p> <p> But, on the other hand, it may not be desirable to have a non-zero return value because an executable launched by the <strong>run</strong> rule has exited with a non-null return value. Some continuous integration tools such as <a class="ext-link" href="http://zutubi.com/"><span class="icon">​</span>Pulse</a> use bjam's return value to determine whether the build was successful or not. In test-driven development conditions, unit tests are meant to fail until issues are resolved. The fact that the unit tests have a non-zero return value does not indicate a build failure - the build may actually have succeeded. </p> <p> Therefore, would it be possible to have bjam return 0 even though one of the programs called through the <strong>run</strong> rule has a non-zero exit code? Or could this feature at least be switched on with a flag? </p> <p> Thanks in advance. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/5514 Trac 1.4.3 Jason Kovacs Mon, 02 May 2011 20:01:33 GMT https://svn.boost.org/trac10/ticket/5514 https://svn.boost.org/trac10/ticket/5514 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">patchfile.patch</span> </li> </ul> <p> Fix suggestion for this problem </p> Ticket Steven Watanabe Tue, 11 Mar 2014 20:56:46 GMT https://svn.boost.org/trac10/ticket/5514#comment:1 https://svn.boost.org/trac10/ticket/5514#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">worksforme</span> </li> </ul> <p> I can't reproduce this problem. Exiting cmd.exe is perfectly fine because Boost.Build creates a separate shell for each updating action. </p> Ticket