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