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
This was detecting the "oldest" VS install instead of the most recent
one when multiple VS installs are available. It's always better to use
the latest one as it will have bug fixes.
Windows drive style paths should also be considered rooted as otherwise
we can't bootstrap when we specify one of those paths. This caused a
regression in Boost where that is regularly used.
Some tests failed because the bootstrap would continue to run even
detecting a problem. This puts in the missing early return statements
in the boost-build builtin rule to get the short circuit on error
like the original Jambase.
This ports the minimal Jambase to native C++. This removes the need for
mkjambase and the Jambase files. To accomplish that it adds C++
utility wrapers around Jam language primitives. Which makes future
similar work much easier.
Rewriting the yyacc utility in C++ makes it ASAN safe and hence makes it
possible to build an ASAN enabled b2 engine. To eventually make all
of the b2 engine ASAN safe.
