* The new scanner is currently disabled and only issues a warning
for tokens that would be lexed differently.
* Special case a few common uses of ':', to limit breakage to
a manageable level.
* Remove the horribly outdated Jambase code inherited from Perforce Jam
* Update all of Boost.Build to work in the presence of the new lexer.
Squashed commit of the following:
commit a777fc2ed9
Author: Brian Kuhl <brian.kuhl@windriver.com>
Date: Fri Jan 12 00:22:37 2018 -0500
configure VxWorks/Dinkum STL to match <rtti>/<exception-handling>
Just a copy-paste of lzma.jam, except not introducing
the useless is-default option.
Will be used for zstd compression/decompression support
in iostreams (see also trac ticket #13356).
* 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.
* Fix problems in x-product that could make it return extra property-sets
in complex cases. Also clarify exactly what it is supposed to do.
* free_features_request.py: This is subsumed by the new test.
* direct_request_test.py: This is mostly subsumed by the new test
except for the last test for chained build-projects, which doesn't
make much sense in the current code base as build-project is implemented
very differently.
* Document using / to separate properties.
* property-set now considers <conditional> to be conditional
* property.evaluate-conditionals-in-context now handles indirect
conditionals as well. This is the correct behavior for all places
where evaluate-conditionals-in-context is currently used.
* Indirect conditionals now translate paths relative to the project
in which they were defined, not relative to the current project.
* usage-requirements no longer use targets.evaluate-requirements,
as the iterative algorithm is completely unnecessary (It's also
wrong, since the new features shouldn't be applied to the evaluation
context).
* indirect conditionals are removed from the property set when they
are evaluated, just list regular conditionals. (This is a consequence
of passing them through evaluate-conditionals-in-context)
* This also allows non-free features in usage-requirements to "work" again
(for some definition of work).
