The mentioned 'standard' path were quite old (9.0, last Intel
compiler version is 15.x as on Oct 2014). Keept the legacy
detection though.
Build in 64 bit (seems more common).
A user is having trouble with calls to setpgid failing
with EPERM and we're not sure whether it's the call to
the parent, or child process that is the source of the
failure. Add check with explicit indication whether
the parent of child failed.
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.
Select was losing child termination signals so we explictly
block SIGCHLD during select, and unblock after select returns.
Tested on 256 core smp system, no hangs or zombies. Thanks
to Alain Miniussi <alain.miniussi@oca.eu> for reporting this.
This change allows top-level scripts to determine which
toolchain was used by Boost.Build engine bootstrap process.
Top-level script of Boost C++ Libraries will be updated
separately.
If we have to wait for, e.g. 65 jobs, first we create a thread which waits for first 63.
The remaining two can be waited on by the same WFMO call which waits for thread
completion. This will avoid creating 2 threads in this case.
Windows WaitForMultipleObjects() can wait on max. 64 handles. This limitation is overcome by splitting the handle set into parts which are of adequate size, and spawning a thread which does the waiting.
