combined-x86-power seems to be completely unused and combined is used only in darwin toolset for Objective-C compilation which seems to be broken for 4 years because it uses gcc.set-fpic-options which was removed in 12decb3ce6.
Boost has three libraries that mentions architecture=combined, I have checked they will not brake after this change.
* features: Support values for instruction-set feature to support Xilinx ZYNQ.
This adds several values for instruction-set (with extensions) to
support various ARM processors associated with Xilinx ZYNQ processors.
These instruction sets are used in various combinations for bare-metal
or FreeRTOS configurations.
* gcc: Support values for instruction-set feature for Xilinx ZYNQ.
Features that are narked as 'free' and 'optional' will now be
ignored when the value specified on the command line is
empty. Hence once can specify `cxxflags=` on the command
line without errors. All current "flags" features are now optional.
fixes#5
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 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.
* Changed icelake to icelake-client and icelake-server. The single
icelake switch is not accepted by gcc.
* Added cascadelake, cooperlake and tigerlake Intel targets.
* Added znver2 AMD target.
* Added c7 VIA target.
* Reordered the list of targets in instruction-set definition
to group targets by CPU vendors.
* Updated toolsets with the new and updated values of instruction-set.
* Updated .py files as well. Added instruction-set values that were
missing compared to .jam files.
* Added cxxstd value 20 for C++20.
The -std=c++20 is supported by clang 10.
* Updated cxxstd=latest for clang 5.0 and newer.
clang 5.0 supports -std=c++17. clang 6.0 supports -std=c++2a.
clang 10.0 supports -std=c++20.
* Updated cxxstd=latest for gcc.
gcc 4.9 supports -std=c++14. gcc 6 supports -std=c++17. gcc 10 will support
-std=c++20.
* Added support for cxxstd=20 to toolsets that don't support C++20.
Adds gnu11 (libstdc++ with new ABI) and libc++ values to stdlib feature.
The value gnu was already in use by sun toolset, so this commit sets it as
libstdc++ with old ABI. Adds support for that feature to gcc, clang-linux and
clang-darwin toolsets. Refactors sun toolset to use stdlib feature via toolset
flags.
* add LTO support
Adds lto feature with 2 values: off (the default) and on. The feature
enables link-time optimizations. Also adds support for the feature to
gcc, clang and msvc toolsets.
* add docs for lto feature
* add lto-mode subfeature
* change lto-mode=full to be the default for uniform behaviour
* make lto feature optional
Add support for a common set of sanitizers supported by both
gcc and clang:
- thread
- address
- undefined
Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
local-visibility is intended to be used by libraries or targets that require
a particular visibility mode. It is not propagated to dependencies. It is
equivalent to the previous visibility feature.
The new visibility feature is a composite propagated feature, so it can be
specified by users and higher level targets as a requirement. This feature is
translated to local-visibility.
The new visibility feature can be used to specify default symbol visibility
on compilers and platforms that support it. The default visibility is
global, which matches most compilers' defaults. In gcc documentation it is
called the "default" visibility. Other modes are: protected and hidden.
* New feature <relevant> which is automatically deduced in most cases.
* Features which are not relevant do not affect target paths and
do not prevent merging of virtual targets.
* generators.jam: generator.run always returns usage-requirements
to allow usage-requirements in non-top-level generators. This
is necessary because we're using usage-requirements to track
relevance from flags.
* New rule toolset.uses-features to specify features that the rule
checks manually, instead of using toolset.flags. In the future,
we should consider restricting the properties actually passed,
to detect errors.
* Adjust tests to handle the new paths (verified by inspection).
* Add temporary option --ignore-relevance to consider all features relevant
to aid migration.
* New rule property.evaluate-conditional-relevance which helps tracking
relevance in <conditional>.
* Widely scattered changes to use the new interfaces.
This moves the built-in feature definitions into a subdirectory where each feature
(or cohesive set of features) are defined in their own file. Eventually
documentation can be added in the definitions files themselves and inported into the
full documentation. Not all features got move by this. There are some features
spread out through the toolset files. Those will also get moved as needed,
and as possible.
