Re: [boost] bcp update, was: The boost component dependencies blues

Subject: Re: [boost] bcp update, was: The boost component dependencies blues
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2009-12-16 14:03:52

On 12/16/2009 01:32 PM, John Maddock wrote:
>>> Can you tell me specifically which headers you're #including so I can
>>> investigate here?
>>
>> I believe the entire Boost.Python API is accessible through
>> boost/python.hpp, so this is what I'm including. (I expect that if there
>> are Boost.Python headers which are not included in the boost/python.hpp
>> 'hub', it's probably an oversight. I may still need them, at some point.
>
> OK, there's an update in Boost.Trunk to bcp so that it only considers 
> library source files to be a dependency if a header declares something 
> that's defined in the source.
>
> As a result using bcp on python.hpp pulls in a lot less....

Many thanks, that's an important improvement !

> but:
>
> Serialization still gets pulled in - you may know that you're not 
> using that particular feature, but as it's #included by the python 
> source you're going to get it anyway.

Out of curiosity, what part of boost.python includes (and uses) 
serialization ? I can't seem to find it with grep.

> MPI still gets pulled in - this is an artifact of some recent changes 
> to boost.graph (which is used by python) to optionally make use of the 
> parallel graph lib depending upon some #define.

I see boost/graph/accounting.hpp includes boost/mpi/config.hpp. Is this 
the culprit ? Can't that dependency chain be broken up, to not have 
boost.python depend on boost.mpi ? (I think this is really a general 
question, not specific to boost.graph. I remember seeing a quite 
rediculous dependency graph generated by Troy Straszheim, and breaking 
out of this would probably be a good idea independently from whether 
someone tries to break out individual components or not. (It may well 
reduce overall compile time.)

Thanks,
         Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...