Boost logo

Boost-Build :

Subject: Re: [Boost-build] How to stop propagate include paths of internal library
From: Phillip Seaver (phil_at_[hidden])
Date: 2009-03-27 14:13:40

Konstantin Litvinenko wrote:
> Vladimir Prus пишет:
>> The reason was that it was cumbersome to employ <use>xxx whenever
>> dependencies
>> should be propagated further, because it was typical that if a
>> library A uses
>> library B, then A's headers also include headers from B and therefore
>> clients of A need B's includes. It is hard to give more details on
>> 4-year old "typical" other than "I found that pretty annoying". I
>> don't think we can
>> change this behaviour right now -- because it would break existing
>> projects.
>> However, we can invent a new syntax to control this -- suggestions
>> are welcome.

Sorry I didn't respond sooner. Work has been keeping me busy.

That's funny, since I have the opposite issue. I mostly try to hide
details, like users of libtiff don't necessarily need to use libjpeg,
libz, etc. :-) I have also run into problems where a library uses a
#define that is used in a different way by another library.

If you want to make it general, I'd suggest something like
<propagate-requirements>foo (though that's pretty long). "foo" could be
"include=yes" vs. "include=no" or "include" vs. "-include".

If you want to solve the specific problem, you could do
<propagate-includes> and <propagate-defines> that take values of "yes"
and "no".

> When I started developing my build tool based on Boost.Build design
> I also hit this nasty problem. My solution was simple and effective on
> practice. I just divide sources on two categories - internal and
> public. So, if A use B internally syntax remains as in Boost.Build.
> But when A use B and B's includes presents in A's public headers than
> I mark B with the special syntax:
> 1) internal usage
> lib B : B.cpp : <include>../include ;
> lib A : A.cpp B : <include>../include ;
> lib C : C.cpp A ;
> 2) public dependency
> lib B : B.cpp : <include>../include ;
> lib A : A.cpp @B : <include>../include ;
> lib C : C.cpp A ;
> In second case B marked with @ that says that B is public source
> for A and all B's usage requirements must be propagated to C. While
> in first case C gets only A usage requirements. I decide to not
> propagated usage requirements upstream uncontrolled because that
> breaks concept of internal and external dependencies. Usage
> requirements propagates only to direct dependencies.
> The same syntax I use to say that some requirements must appear in
> usage-requirements:
> lib A : A.cpp : @<include>../include ;
> is equivalent to
> lib A : A.cpp : <include>../include : : <include>../include ;
> That makes my life much easy. And this is much less verbose and more
> readable, I think :).
> I understand that my way is opposite to current usage requirements
> behavior and changing that is break everything, but may be it would
> usefull for you....

I like the simplicity of this approach, but the "@" symbol doesn't make
it obvious whether it's public or private. Prefixing with "+" or "-"
(depending on what the default propagation is) might be more clear,
though you may already be using one of those for something else...


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at