Re: [jamboost] Re: propagation of usage-requirements

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
<Jamfile>
lib libB : b.cpp : <include>path_to_A ;
</Jamfile>
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
<jamfile>
lib libA : a.cpp : : : <include>path_to_A ;
</jamfile>

So both kind of dependencies are now supported.

toon