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.
feature.py:
Use the feature's name in the error output. This helps in understanding the
error message.
project.py:
The original looked like the result of a bad merge as the return value was the
exact same as the return within the try...except block. The try...except
produces a better error message upon failure.
property_set.py:
The string module is unused.
virtual_target.py:
ARM's ar.exe would fail when passed a path to the -via file that had both
POSIX and Windows path separators. Normalizing the path on the target solved
the problem.
common.py:
The requirement parameter in check_init_parameters should be a container. The
original Jam signature marks it as a list with zero or more items. These
changes convert the requirement parameter to using only a container.
msvc.py:
The call to to_seq asserts that command is always some container. So, extend()
should always be used.
tools/rc.py:
Old style exceptions aren't allowed (at least in Python 2.7). This change just
uses the existing AlreadyDefined exception.
testing.py:
loaded_tool_module_path_ is empty upon initial import. Using the __file__
variable instead will always work (provided the import system doesn't change).
This patch fixes 3 issues:
- Adds support for Intel-15 so MSVC version can be auto-selected.
- Changes GLOB to path.glob as for some reason the GLOB rule always
fails when used in this context (discovered when testing this patch).
- Changes selection logic for target-types variable - previous code
used the value of PROCESSOR_ARCHITECTURE to detect this, but that
appears to only tell you which sub-system bjam is running in. For
example on my system bjam is a 32-bit app (default for an msvc build),
but I only have the Intel 64-bit compiler installed (under /intel64/).
New logic checks whether the intel64 compiler exists and uses that if
it is - Intel's installer won't install this on 32 bit platforms in
which case the glob fails and things fall back to the ia32-intel64
cross compiler when address-model=64 is specified.
