Boost logo

Boost :

Subject: Re: [boost] Link dependencies
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2014-12-03 04:48:18


On 12/03/2014 11:53 AM, Andrey Semashev wrote:

>> Comments?
>
> Such mechanism would require modification to the MPL Jamfile, am I correct? I
> generally don't like when I have to manually describe dependencies, because
> when the code is modified these descriptions often get overlooked.

I was thinking more about "Whenever <mpl/...> include is found, add dependency
on every MPL header".

> However, if
> the description is made on the sublibs level (i.e. that "libs/mpl depends on
> libs/mpl/core" and that makes all MPL.Core headers linked) this might be ok.

> Why not just run the headers target before building anything. b2 headers does
> the right thing, and any project inside Boost implicitly relies on the boost/
> directory tree. I was trying to accomplish that by modifying the
> tools/regression/build/Jamroot.jam (see my pull request). My reasoning is that
> since b2 cannot deduce #includes from headers in cases involving preprocessor,
> like in MPL, we should not rely on it and just always link all headers.

It is an option, yes. It's not entirely perfect because all headers will be linked
even if you build a single library.

> By the way, do you know why implicit-dependency on the headers target in that
> Jamfile does not work? My understanding is that its intention was exactly what
> I suggested above.

Because the effect of 'implicit-dependency' is:

        1. When you see include of a header ...
         2. ... check that other target mentioned by implicit-dependency ...
         3. ... and it's generating such header ...
         4. ... add dependency.

In our cases, preprocessor magic hides the fact that gcc/or.hpp is included, so
the process breaks at step 1, and whether we have implicit-dependency or not
no longer matters.

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk