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-05 04:50:24

   Hi.

>    When I get the time next, I'll look into these are being reported as
> ambiguous property sets since the <warnings> feature should be declared
> as 'incidental', i.e. as 'not having an impact on the final built
> executable' and should therefore be ignored when deciding whether two
> virtual-targets (Boost Build lingo for 'an actual target file with an
> accompanying property set') are equivalent.

   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 ;

   Note that once the boost_system library build project module gets 
loaded it does not matter whether you use absolute project references or 
the project-id defined by the use-project rule since the project module 
has already been loaded by the time you reference it.

   This whole 'module loading' procedure is something to look into but 
this should provide you with a cleaner workaround.

   Best regards,
     Jurko Gospodnetić