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

Subject: Re: [boost] bcp update, was: The boost component dependencies blues
From: John Maddock (john_at_[hidden])
Date: 2009-12-17 07:03:20

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