Re: [boost] Link dependencies

Subject: Re: [boost] Link dependencies
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-12-03 05:19:14

On Wednesday 03 December 2014 12:48:18 Vladimir Prus wrote:
> On 12/03/2014 11:53 AM, Andrey Semashev wrote:
> > 
> > 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".

Hmm, that means to hardcode MPL somewhere, and this won't scale for other 
libraries, if we go on modularizing. I'd prefer a more general solution - 
ideally, totally automagic and transparent, otherwise, if not possible, at the 
library developers' control.

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

Well, yes. In the long term, when we support modularized builds this can 
probably matter, although not necessarily so. I imagine, when Boost gets truly 
modular, one would download sources of the needed libraries separately, and to 
build them one would have to link all headers from these libraries anyway.

With the current state of affair, I don't think there's a problem to link all 
Boost headers regardless of the built libraries, at least for testing. I mean, 
we have to do this anyway in order to test and distribute Boost, and I bet no-
one is trying to build Boost themselves from git without running 'b2 headers'. 
AFAIR, no-one complained about it so far.

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

I see, thanks. So, in order to resolve the problem with testing, do you think 
my pull request[1] is valid? It basically changes 'implicit-dependency' to 
'dependency', which, I assume, is not conditional on the included headers.

[1] https://github.com/boostorg/boost/pull/39