Boost logo

Boost :

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-24 16:04:23

On 4/24/19 12:12 AM, Mike via Boost wrote:
> > Hmmm - so no boost library should include any
> > other boost library? Does that seem a good idea?
> Please don't put words in my mouth. I didn't say that
> and you know it.

Hmmm I was responding to the comment
> >when I just want to use
> > library X, the rest of boost doesnʼt come as a
> > dependency with it.
I don't know any other way to read it.

But the dependency graph could
> easily be significantly simplified once c++03 is no
> longer a concern.

Hmmm I'm not sure what "no longer a concern means" in user code, in
library code or ???. In any case, I don't think more/less C++03 will
not affect this issue.

Again: I'm talking about the
> future, not the current state.
> Just an example: [1]Boost.TypeErasure depends on
> [2]Boost.Thread(and all that entails), just because
> somewhere in its bowels it needs a mutex.
> > It's always been good practice to not repeat/copy
> > functionality in one library into another.
> Not always. A recent example I stumbled over:
> Boost.Signal2 depended on boost multi index (which
> itself depends on a lot of other libs) because it
> reused it's scope guard implementation
> (IIRC about 50 lines of straight forward code).
> Tying yourself to another library for something
> trivial like that should not be a no-brainer.

> > But what is really needed - and it may already exist
> > in BCP but hasn't been promoted is a simple tool:
> > a) start with one's application
> > b) run the app through a tool which recurrsively
> > reads headers
> > c) and creates a list of all headers needed
> > d) extract library names from that list
> > e) add the git repo of those libraries to my apps
> > project.

> So boost should not only get its unique build system, but also its
> unique dependency management tool?

Such a tool would not be tied to boost. The issue of dependency affects
all large programs. Such a tool as described would be useful to any
large project.

> I can tell you as a user: Thanks but no thanks.

LOL - Sure - it's a free country.

> Also: Didn't you forget source files somewhere in
> there? What about tests?

The above describes the scenario in which such a tool would be used to
support the tracking of dependencies in any large project. If this
project was one small app - the procedure would apply to just that app.
If the one wanted to includes a test suite - the procedure would be
applied to the union of all the programs in the test suite.

> Bottom line: If boost as a whole was developed as a single project with
> some coordinated devlopment
> goal and strategy , it would make sense to distribute
> it as a single package/framework and a single
> cmake config file.

> It seems to me however, that it
> is more a (huge) collection of independently
> developed libraries, so I think it is more appropriate
> to treat them as such


> even if there is a huge amount of coupling between them.

Hmmm - this is the rub. The coupling is supposed to be narrow through
type and function interfaces exposed in header code. (to a lesser
extent it extends to separately compiled library code as well.) The way
to deals with this is to keep the interfaces narrow. I believe that
Boost libraries actually do do this. It's the framing or notion
dependency in terms of library rather in therms of headers which leads
us in the wrong direction.

> References
> 1. http://Boost.TypeErasure/
> 2. http://Boost.Thread/

Although this problem is most frequent with the serialization library,
it occurs with other libraries also. In some communications, they are
referred to as "glue libraries" or "bridge libraries". It might help if
this notion was formalized in some way.

Robert Ramey

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