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: Vladimir Prus (ghost_at_[hidden])
Date: 2009-03-16 14:33:21

On Monday 09 March 2009 15:53:01 Phillip Seaver wrote:

> > I have the problem than my build command line gets to big for windows xp
> > due to too much include paths. 

Hmm, are you using gcc? 

> > The problem is that all include paths are
> > propagated up through all the libraries even if the library is only use
> > internal (just in source files). Here a simplified example:
> >
> > I Have an executable Exe which depends on library LibB which depends on
> > library LibA but only in the source files so Exe would not need the
> > exported include paths of LibA to compile.
> >
> > I could not figure out how I can prevent that the includes of LibA are
> > propagated to Exe. Can somebody help me?

> I describe how I do it here:
> http://lists.boost.org/boost-build/2008/12/20976.php
>
> I prefer it that way to avoid header conflicts between third-party
> libraries and reduce my search path.  I don't recall whether I ran into
> the command-line limitation, but I wouldn't now, since the msvc toolset
> uses "response files" to reduce the command-line size.

It looks like I have missed your original email. Anyway, originally
includes, and other usage-requirements, were propagated only to
direct dependents. It was then changed to current behaviour here:

        https://svn.boost.org/trac/boost/changeset/26528

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.

- Volodya