Re: [Boost-build] How to stop propagate include paths of internal library

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

Phillip