Re: [Boost-build] Build error when adding Boost libraries to own projects

Subject: Re: [Boost-build] Build error when adding Boost libraries to own projects
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-08-06 17:35:41

   Hi.

>    I have not yet had the time to look into this but while working on
> another issue in Boost Build I ran into what could be the cause for this
> problem as well... :-)
>
>    It seems your example uses absolute (I'm possibly missing some better
> term here) external project references, i.e. you reference targets from
> those projects like this: absolute-path//target. Also, nothing you do
> tells Boost Build to load those project files with all the other project
> files at build startup and it then loads them only as an after-thought,
> when resolving external target references, which comes too late. I have
> not really tested this in detail yet but it has most likely already done
> all the property analyzing at some point and stored the 'warning'
> property without knowing that it was actually incidental and should be
> ignored in this case. Or something similar...
>
>    A 'nicer' workaround for you is to let Boost Build know you are using
> the Boost library targets by calling the use-project rule in your
> Jamroot module.
>
>    For example, I added the following line to your Jamroot module and it
> 'fixed' the original problem:
>      use-project boost : $(TOP)/external/boost/libs/system/build ;

   Ok, I managed to research this some more now.

   The problem is indeed caused by absolute module references causing 
those modules to be loaded too late. And this is what happens:

   1. Regular project modules are loaded, which then define different 
features.
   2. Boost Build now starts generating targets needed to build the 
requested main targets.
   2.1. It finds out it needs to build one target with a certain 
property set.
   2.2. It encounters a source ids containing an absolute module 
references and loads that module which in turn defines a new 
non-incidental feature with a default value. [In our case that is the 
<threadapi> feature defined by the thread library build script.]
   2.3 It finds out it needs the same target from step 2.1 as a source 
again but now its property set is a bit different and the difference 
contains the non-incidental property from step 2.2 so it creates a new 
virtual-target even though 'the right thing to do' would be to reuse the 
original virtual-target.

   I'll prepare a separate post to discuss what can be done about this 
in Boost Build itself to better handle this situation, but I think a 
'clean workaround' for this is to not use absolute project references in 
source ids but to load all project modules explicitly using the 
use-project rule.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić