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

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
>>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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com