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.
My mistake, it's pulled in by MPI.
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.)
The problem here is present in pretty much every graph and property_map header, something like: #ifdef BOOST_GRAPH_USE_MPI #include <boost/property_map/parallel/distributed_property_map.hpp> #include <boost/property_map/parallel/local_property_map.hpp> //... #endif which means that the MPI dependency is conditional on whether BOOST_GRAPH_USE_MPI is set almost no matter what graph header you include. BTW this has an impact for build tools like bjam (probably others as well) that perform quick regex based dependency analysis rather than preprocessing to build the dependency tree. As a result the graph headers will get marked as out of date if any MPI or serialization header is out of date, even if they're not actually being used :-( John.