From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-01-06 16:52:16
I have added a new tests (default_toolset.py) demonstrating problems
with Boost Builds default toolset handling. The tests pass fine if you
tweak them to explicitly use their toolsets instead of telling Boost
Build to use them 'by default'.
Basically, all related problems come from the fact that the default
toolset gets used/loaded/imported only after the built project files get
loaded. On one hand - that makes sense as it allows the project to use
its own toolset if it wants to. On the other, project file
interpretation depends on the knowledge available only after a toolset
is used, so it implicitly requires that the toolset be used before those
files get loaded (or at the very least - before any such toolset data
interpretation is done).
1. When a main target is created it copies into its requirements all
toolset requirements defined for the toolset identified by its <toolset>
feature. However, those toolset requirements will not be defined at that
point and will therefore be ignored if the default toolset is used.
2. When you have a property conditioned on a toolset version
subfeature then that property is not applied when building targets with
the default toolset. This is because such conditional properties get
parsed directly when first mentioned according to the toolset subfeature
definition and that definition is not yet available at that point.
When this is fixed then ticket #147 should be closed as well
(Microsoft Visual Studio .NET 2003 and 2005 compiler crash when
compiling boost under some circumstances).
1. Remove the whole default toolset functionality.
2. Make the default toolset be used immediately after reading in
configuration files. That way the problem goes away but then project
files defining their own toolset usage (e.g. in a Jamroot file) might be
surprised as the default toolset will have a higher priority than their own.
3. Make constructing targets not depend on toolset definitions at all
but instead only record the user provided information. Then any such
information will get interpreted as needed only when first needed in the
virtual-target construction phase which comes after the default toolset
My preferred solution is 3 but it is also the only non-trivial one to
implement. I looked at it a bit and the problematic code seems to be the
one for 'parsing main target parameters' located in:
- targets.main_target_default_build (expects implicit features to be
- targets.main_target_usage_requirements (expects paths to be defined
as well as features and subfeatures)
- targets.main_target_requirements (expects paths to be defined as
well as features and subfeatures)
- worker property-set.***-from-user-input rules.
Any other thoughts on how to fix this?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk