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
> 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
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
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
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
Hope this helps.
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