
If you run bcp, every library shows up as depending on test and mpl
I don't think so. When I tried it yesterday there was no mention of Boost.Test headers in the Boost.Parameter dependency report.
It depends how you run it: basically it scans files for file dependencies so: If you pass it a list of *library names* to scan, and those libraries have tests that depend on "whatever" (Boost.Test etc) then you get a very fat dependency graph. However if you're more disciminating and pass the name of the headers you use, then you get a list of dependencies for those headers, for example: bcp --list regex => Big fat list including Boost.Test and Boost.Thread bcp --list regex.hpp => Slimline list, just what the headers and source depend on. bcp --scan --list myfile.cpp => Whatever Boost headers/source myfile.cpp depends on. And yes this is all in the docs :-) Also don't forget that the output from bcp is made more verbose by the need to create a dependency chart that works for any compiler: your specific compiler may need only a fraction of what bcp reports, in some cases anyway. Someone asked about producing a library dependency chart: there are two problems with that: There are many libraries that depend on just one or two files in otherwise quite large libraries such as MPL, Preprocessor, Type Traits etc. Do these depend on those libraries? It's quite hard to map some header files (those direcly in boost/) to library names: we could make a manual list to do the job, but it would be a non-stop job keeping it up to date. What I will investigate though is collapsing the output from bcp --list so that boost/foo/* all map to a single entry boost/foo libs/foo/* all map to a single entry libs/foo which would cut down the list output a lot. John.