Subject: Re: [boost] Extensive interdependencies in Boost
From: Jens Weller (JensWeller_at_[hidden])
Date: 2013-10-17 18:03:52
> Gesendet: Donnerstag, 17. Oktober 2013 um 23:53 Uhr
> Von: "Philip Bennefall" <philip_at_[hidden]>
> An: boost_at_[hidden]
> Betreff: [boost] Extensive interdependencies in Boost
> Hi all,
> I have been doing some tests with bcp recently, and the number of files I
> get for even the smallest header-only libraries (at least on the surface) is
> quite surprising to me. I know that not all files are used for compilation
> on a given platform, but I would still like to avoid putting 1253 files
> (11.7 MB) in my source tree just because I use a tiny part of Boost
> (boost/unordered_map.hpp in this case).
I know what you mean, but have a little different opinion on it.
I'm the author of the boost dependency analyzer, which is also bcp based, so I do have some expierence at looking at its results:
So my opinion on this:
First you must understand, that bcp will give you the MAX Dependencies of any lib, this means it will export everything that could be ever used with the lib you have choosen.
This can include tests, it includes the inner, normally not directly visible dependencies in boost (config f.e.), and the may-be-you-also-will-want-to-use-this-boost-lib dependencies.
For example a library supports handling of shared_ptr, you see this as a dependency in bcp, even if your own code doesn't use shared_ptr.
So, what bcp exports is always - as far as I understand - all the dependencies that could exist. So yes, you get the whole package.
> I am wondering, will the effort that I have been reading about to modularize
> Boost, attempt to reduce some of these interdependencies? Or is the idea
> more about reducing the download size of the Boost distribution itself?
Not involved in this work, so I can't answer it, but same as with bcp I think you run into the problem of not knowing which dependency is actually not needed/used by the user.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk