[Boost-build] Library usage requirements propagation (Was: PCH problems (was: removing propertiesfrom a property s)

From: Phillip Seaver (phil_at_[hidden])
Date: 2005-12-15 12:33:52

David Abrahams wrote:

>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
>>>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?  
>>    
>>
>
>The former.
>
>  
>
>>(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.  
>>    
>>
>
>How so?
>
>  
>
>>The users of a library don't necessarily need to have the defines
>>and includes from the libraries it uses.
>>    
>>
>
>Correct.
>
>  
>
>>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.
>>    
>>
>
>Agreed.
>
>  
>
>>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.
>

Sorry about quoting everything, but I thought it would be easier than
telling people to look for the older posts.

So, does anybody else have an opinion on this?  Unfortunately, I don't
have time at the moment to figure out how it all works, or I'd do it
myself and submit a patch.

Phillip