From: David Abrahams (dave_at_[hidden])
Date: 2004-12-17 08:59:28
Toon Knapen wrote:
> 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.
The author of libB should never have to specify <include>path_to_A,
whether he wants those include paths to be propagated on to his
dependents or not.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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