Boost logo

Boost :

Subject: Re: [boost] Extensive interdependencies in Boost
From: Philip Bennefall (philip_at_[hidden])
Date: 2013-10-17 18:14:22

Thanks, Jens. What you say makes sense. I guess my next question would
become, is it perhaps possible to extend bcp to be a little more selective?
Since Boost already has a preprocessor implementation, maybe this could be
used to follow some macro paths to determine what needs to be included? The
user would naturally have to specify some macros that bcp could work with,
but this seems to me to be an effective way of making bcp a little more
picky when generating its output depending on the user's needs.

Another, perhaps less realistic option, would be if bcp could actually
analyze what parts of a certain library the user's code calls upon. For
instance, if I never use a smart pointer for a given container we would not
need that dependency. This, I realize, is far more involved and might not be
at all practical to implement. I'm just throwing the suggestion out there
for some discussion.

Kind regards,

Philip Bennefall
----- Original Message -----
From: "Jens Weller" <JensWeller_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 18, 2013 12:03 AM
Subject: Re: [boost] Extensive interdependencies in Boost

Hello Philip,

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

kind regards,

Jens Weller

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at