From: David Abrahams (dave_at_[hidden])
Date: 2005-12-06 17:53:48
Phillip Seaver <phil_at_[hidden]> writes:
> 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
>> 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.
So, something like
lib a : $(ASrc) : : : <include>./include/a ;
lib b : $(BSrc) : : : <include>./include/b <use>a ;
if they do need to be propagated?
> 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 ;
Where's that <use>?
> 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.
Agreed. I think you're on the right track.
-- Dave Abrahams Boost Consulting 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