* 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.
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 implements two styles of install layouts for B2: standard and
portable. This uses the new symbolic stage install locations. The
portable layout creates a structure relative to the B2 executable.
And hence allows for moving the B2 executable anywhere. This is
important for Windows and MacOS where there is no reasonable
packagining structures.
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.
When using conditionals the location, if using replacements, would get
mungerd as the replacement part would fall in the middle of the path.
Using a custom translate-path rule we can prevent the munging
from happening before it gets to back to the stage target class.
The translate-path feature allows for custom path handling, with a
provided rule, on a per target basis. This can be used to support custom
path syntax.
It's useful to set up stage install dirs as aliases to others to allow
for external overrides. This makes it possible to also have such
aliases without needing to make them a sub-path of an
existing dir path.
* a feature to control install prefix for install targets
* usable default for install-prefix on Windows
* additional named installation prefixes based on Autotools
* allow users to add named installation directories
* fix named directories <location> handling when requesting a subproject build
* examples for named installation directories
* document named install directories-related functions, make get-package-name more conveninent to users
* feature to allow staging into a location different than active install-prefix
* support for getting relative paths with stage.get-dir
The feature is enabled by default only for MSVC 11 and above not to break
derived toolsets.
Unfortunately, it cannot be enabled on clang-cl with MSVC linker at the moment
because it because of some path issues:
```
>clang-cl test.cpp /link /manifest:embed
LINK : fatal error LNK1158: cannot run 'rc.exe'
clang-cl: error: linker command failed with exit code 1158 (use -v to see invocation)
```
Note: `embed-manifest-file` feature was broken before the change and still is
broken under `embed-manifest-via=mt`. The fix seems to be obvious, but I am not
fully understand what happens inside link/link.dll rule to fix it here.
