[Boost-build] Default toolset problems in Boost Build.

From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-01-06 16:52:16

   Hi.

   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'.

   Changeset: http://svn.boost.org/trac/boost/changeset/42549

   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).

   Examples:

   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).

   Possible solutions:

   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 
is selected.

   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 
defined)
   - 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?

   Best regards,
     Jurko Gospodnetiæ