Boost logo

Boost-Build :

From: Phillip Seaver (phil_at_[hidden])
Date: 2005-06-15 08:39:27


Vladimir Prus wrote:

> On Wednesday 08 June 2005 21:52, Phillip Seaver wrote:
>
> > It would be nice (from my perspective, of course :-) ) if this worked
> > such that the link requirement would be propagated and building d would
> > use the include for e, but the include didn't get propagated. This is
> > with static linking, BTW.
> >
> > exe a : a.cpp b ;
> > lib b : b.cpp c ;
> > lib c : c.cpp d ;
> > obj d : d.cpp e ;
> > lib e : e.cpp : : : <include>. ;
> >
> > The reason is that d uses e, but the users of c (and the rest of the c
> > library) don't use e directly, so they have no need for e's headers.
> >
> > What do you think?
>
> I recall it used to work this way, but lead to user complaints. The
> behaviour
> was then changed so that usage requirements are propagated all the way up,
> not only to direct dependents. Of course we can introduce a syntax to
> propagate usage requirements only to direct dependents, but I don't
> see this
> as too important.
>
> - Volodya

I've been playing around with this a little, to see if I could figure
out what's going on inside boost.build (no luck so far :-) ). I created
a test project for this, and I discovered that the behavior is different
between link=shared and link=static (this is in m10 -- I haven't tried
it with the latest):

> lib sublib : lib/sublib/sublib.cpp : : : <include>lib/sublib ;
> lib mylib : lib/lib.cpp sublib : : : <include>lib ;
> exe test_use : test.cpp mylib ;

For link=shared, it just includes sublib in the link line for mylib and
doesn't propagate the include to test.o or the lib to test_use. For
link=static, it adds sublib to the link line for test_use and adds the
include to the compile command for test.o.

As far as controlling the propagation, couldn't you just use the <use>
feature? If I change the mylib line to "lib mylib : lib/lib.cpp sublib
: : : <include>lib <use>sublib ;" it propagates the include for sublib
to test.o for the link=shared build.

Obviously, this isn't critical (since it builds correctly) but in my
project that would remove multiple includes from 80+ files.

Phillip

 


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