1. cmd.exe quirk 1: `exit /b 1` sets error code `0` for **the process**, even though it sets `errorlevel` to `1`.
2. `bootstrap.bat` needs to check that `build.bat` succeded (cmd.exe quirk 2: `echo off` doesn't change `errorlevel`).
3. `build.bat` overrides exit code with call to `dir *.exe`.
4. `setlocal` will rollback `pushd` on exit (that also helps with Ctrl+C).
This adds a check_cxx11.cpp source that is checked for compile with the
chosen toolset before actually building. This include an appropriate
user error. To see such errors, we also nolonger output to
bootstrap.log. Instead the bootstrap outputs to cerr and sets the
error code.
Technique used for setting Windows batch script exit codes in Boost.Build worked
correctly when the script is called from a Windows shell process and then checked
from inside that process. However, when run from a temporary shell process that
needs to terminate after running the script, such a process would always return
exit code 0.
This prevented anyone automating those scripts from detecting their success/
failure status by using their exit code without adding an additional batch script
layer.
For example, consider the following two script files:
ret666.cmd:
exit /b 666
wrapper.cmd:
call ret666.cmd
They both 'should return the value 666' and when run directly from a cmd.exe
console indeed both do (they set the shell process's ERRORLEVEL environment
variable to 666). However, when run like this:
cmd /c <script-name>
running ret666.cmd causes the temporary cmd.exe process to exit with exit code
666, while running wrapper.cmd causes it to exit with exit code 0.
