I'm not sure what the best place is for this question, but since it is symptomatic for a general theme (which I have complained about a lot in the past), I'll write it here:
I'm trying to generate a boost subset that allows me to build boost.python and its dependencies into my own package. To do that, I ran "bcp python ...". I'm surprised to find all these components in the generated source tree:
date_time, graph, mpi, regex, serialization, test, thread.
And that's only compiled components (content of lib/). There are many more header-only components (i.e. subdirectories under boost/), such as spirit, variant, property_map, property_tree, dynamic_bitset.
Is this really a minimal subset to use boost.python ? I can't quite believe it. In particular, what is boost.mpi doing there, and what boost.serialization (and boost.spirit) ?
OK, there are two issue here... why is the dependency so "fat", and why is component X a dependency of Y? To start with the first one: you've created an unnecessarily "fat" dependency because "bcp python" pulls in all of libs/python and its dependencies - for example all the headers and other libraries that the tests and examples depend upon, and since Boost.Python is a big library it's not surprising that this pulls in almost all of Boost. If you know specifically which headers you are using, then "bcp some-boost-header.hpp" will create a much more slimline dependency tree - or at least it should :-) You can also use bcp with the --scan option to scan your actual source files/headers for their Boost dependencies and just copy those actually used. For the second one, if you use bcp with the --report option, it will create a HTML report rather than actually copying the files, that report contains a full dependency tree, so you could look up say Regex or MPI and track its dependencies back to python. There is one potential SNAFU waiting here... say there is a dependency on foo/bar.hpp and lib foo has source files in libs/foo/src/. Those source files will automatically get included as a dependency (which in turn triggers a whole load of other dependencies), but potentially, for a few libraries at least, header foo/bar.hpp may be a header only component of lib foo. Remember also that bcp is compiler agnostic, so all the compiler workarounds are pulled in, regardless of what actual compiler you may be using. That's a feature not a bug BTW ;-) HTH, John.