Robert Ramey wrote:
a) doesn't include any *.cpp files. So I assume that it contains less than the true number of dependencies. That is if a *.cpp file includes a header as part of it's implementation and not it's interface, it wouldn't be included.
There isn't one true number of dependencies. There are at least three, and (a) produces one of them. 1. The .hpp dependencies. These are required if one wants to use the library. 2. The .cpp dependencies. These are required if one wants to build the library. 3. The test dependencies. These are required if one wants to run the library's tests. For header-only libraries, (2) obviously doesn't apply. (3) is a superset of (2), and (2) is generally a superset of (1). I've chosen to focus on (1) in my report both because the libraries with which I'm most concerned are header-only, and because its transitive closure gives a better approximation of the indirect dependencies of a library. Libraries sometimes include another library's headers without actually needing the compiled library for ordinary use. The dependencies on Serialization are generally of this sort - if you don't serialize a, say, variant, you won't need to link to Serialization and consequently don't need to have it built, but the headers must still be there. But of course if you want to know what do you need to build a library, you need (2), not (1). And similarly, if you want to know what you need for a library's tests, you'd need (3). Neither is truer than the others, as they are fit for different purposes. A transitive report based on (3), for instance, would be nearly useless - many libraries use Boost.Test, and Boost.Test depends on the world.