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: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-03-30 02:28:11

Phillip Seaver wrote:
> 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".

We had a related discussion here a while ago. What do you think about the 
following:

http://thread.gmane.org/gmane.comp.lib.boost.build/20251/focus=20281

/ Johan