In the case where multiple @() substitutions happen in one action the
dynamic choice of file vs content would apply to all. This would cause
problems as some of them might not be command options. This change
adds an ":O=" options specifier to variables that can control what type
of @() substitution can happen for each expansion. By specifying "O:=FC"
one can select to allow either file or content expansion making that @()
instance dynamic. When not specified the default is as if "O:=F".
* Define OSMINOR & OS_HURD on GNU/Hurd
Add a way to identify GNU/Hurd with b2, and also in the Python support.
* Use /proc/self/exe for executable_path on Hurd
Use the Linux compatibility procfs translator to get the full path of
the current executable.
* Define _GNU_SOURCE on any GNU libc-based OS
Make sure to enable GNU features when building on any OS that uses
GNU libc.
For bootstrapping `b2` itself, the current `borland` toolset is broken
now as `bcc32.exe` doesn't support C++11. Update that toolset to use
the Clang-based `bcc32c.exe`, which has largely the same cmdline args.
This implements the ability for response file "@()" substitution to
dynamically adjust to either expand the content or create the response
file depending on the possible command line length. This should
reduce the create of such response temp files improving build
performance.
The executable_path allocates a string (strdup) which was never released
Tested with ASAN and valgrind
Co-authored-by: Miroslaw Stein <miroslaw.stein@isode.com>
When the Jambase got ported we lost also searching BOOST_ROOT for the
bootstrap file. This is strictly a backward compatibility fix for Boost.
fixes#622
* repace icc with "official" icpc driver with intel-linux
* the right dialect selecton option needs a space with intel-linux
* Check for oneapi setvar script with intel-linux
* Consider oneapi from Intel if compiler not provided.
* Fix comment about fallback when looking for compiler
Even for 64-bit architectures, b2 would add '-arch arm' to the compiler
options - but this is only valid for 32-bit arm builds.
The problem was also observed here: https://stackoverflow.com/a/47096479
The reason for limiting links to one at a time is long obsolete. Hence
we can remove almost all uses of JAM_SEMAPHORE to impose that
one-link-at-a-time limit.
