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: Konstantin Litvinenko (to.darkangel_at_[hidden])
Date: 2009-03-16 17:43:27

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.

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