Boost logo

Boost-Build :

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

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

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