Re: [Boost-build] [BBv2] PCH problems (was: removing propertiesfrom a property s

From: Phillip Seaver (phil_at_[hidden])
Date: 2005-12-06 16:42:10

David Abrahams wrote:

>Phillip Seaver <phil_at_[hidden]> writes:
>  
>
>>lib a : $(ASrc) : : : <include>./include/a ;
>>lib b : $(BSrc) a : : : <include>./include/b ;
>>lib c : $(CSrc) b : : : <include>./include/c ;
>>exe D : $(DSrc) c ;
>>
>>I would prefer that ./include/a not be added to the compile lines for c
>>and d.  It would make the command-lines shorter and avoid incorrect
>>header includes.  If I wanted to propagate a's requirements from b to c,
>>I could just use <use>:
>>
>>lib b : $(BSrc) a : : : <include>./include/b <use>a ;
>>    
>>
>
>It seems like the right place to note that b's headers don't #include
>a's headers is in the specification of b.  So it should be something
>like:
>
>
>  lib a : $(ASrc) : : : <include>./include/a ;
>  lib b : $(BSrc) <nopropagate>a : : : <include>./include/b ;
>  lib c : $(CSrc) b : : : <include>./include/c ;
>  exe D : $(DSrc) c ;
>
Are you suggesting adding "<nopropagate>" or is it in CVS?  (I haven't
updated in a few weeks since I've been in the middle of a project and
didn't want to chance breaking my build system :-) )

My preference for the default would be to not propagate library usage
requirements beyond the direct dependent.  It would be nice if I could
do this for objects, too, so that I could encapsulate a library.  The
users of a library don't necessarily need to have the defines and
includes from the libraries it uses.  If they need them, the Jamfile for
that library should explicitly add them to the usage requirements
(probably via <use>).  For example:

obj f : f.c a ;

lib e : $(ESrc) f ;

Or, for a more real-life example:

lib z : $(ZSrc) : : : <include>. ;

obj tif_zip : tif_zip.c z ;

lib tiff : $(TIFFSrc) tif_zip : : : <include>. ;

obj tiff_image : tiff_image.c tiff ;

lib image : $(ImageSrc) tiff_image : : : <include>. ;

exe D : $(DSrc) image ;

D doesn't need the includes or defines for zlib or libtiff, so I don't
think it should get them.

Another issue is duplicate header names and, to a lesser extent in my
experience, duplicate defines.  No propagation beyond direct dependents
would make this easier to deal with.

Phillip