From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2004-12-16 11:38:08
David Abrahams wrote:
> I have a lot of sympathy for the idea that mysterious unneeded #include
> and library search paths shouldn't show up in a target's build command
> just because of some long dependency chain. People will eventually (for
> debugging purposes at least) want to know what concrete command was used
> to build their software and it will be confusing and probably
> distressing if there's a bunch of unneccessary garbage in the
> command-line. That's one reason I feel strongly about eliminating the
> ../../../../back/to/my/directory chains. If nothing else they induce a
> lack of confidence in the build system.
> There ought to be a way to say "these are propagated only to direct
> dependents." In fact, I think that maybe ought to be the normal case.
Indeed and actually there is now the possibility to do that. As for
dependencies we should distinguish header- and source-file dependencies
or better terminology is propagating and non-propagating dependencies.
A public header file of library B that includes a header file of library
A induces a header- (or propagating) dependency from library B to A.
Because all code that includes this header file of library B will need
to be able to find the specified header files of A too.
If only source files of library B include headersof library A, the
dependency is non-propagating.
The latter kind of dependency will result in soth like
lib libB : b.cpp : <include>path_to_A ;
Users of 'libB' will 'inherit' the requirement to include 'path_to_A'.
With the new behaviour of the usage-requirements, the propagating
dependency is expressed via the usage-requirements like so
lib libA : a.cpp : : : <include>path_to_A ;
So both kind of dependencies are now supported.
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