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