Boost logo

Boost :

Subject: Re: [boost] To modularize, or not to modularize. What is the plan?
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-05-07 01:16:57

On 5/6/19 4:47 PM, Rene Rivera via Boost wrote:
> Bringing this up because of the recent discussion in the 1.70.1 thread. And
> of course because this is the week that a certain BSC meets. Hence I
> thought I would clarify what I've meant my a modular Boost all this time.
> A modular Boost, to me, means a Boost that first and foremost a collection
> of independently consumable C++ libraries.


That would have the following
> aspects to it:
> * An end user or library author can obtain a single Boost library of their
> choice and use it in their project, assuming they also obtain the
> appropriate dependencies of that library.


> * BoostOrg would not produce a monolithic, combined, merged, etc
> distribution.

I don't see it as necessary for Boost to give this up. That is, I don't
see the current setup as conflicting with the ability to just download
the libraries he wants.

> * BoostOrg would produce collectively tested milestone modular
> distributions.

I don't think anything has to change here.

> Sounds lovely right? ...I'll leave the discussion of merits to responses
> herein ;-)

I envision the construction of a tool which just goes to github and
downloads a list of boost libraries. For each library the download
process makes a simple transform to a standalone directory for that
library. Similar to what the global distribution currently looks like
except for one library at at time.

This would be useful right away. In vinnies 1.70.1 situation, one could
put this to use right away.

a)the user changes the name of the current beast directory to beast-1.70.
b)downloads the latest from the master into the new beast directory.

> What would it take to reach that modular goal? Why do I keep saying we've
> been working on this for ages and ages? Briefly here's what it would take
> to get there (not in any particular order):
> * Abandon the single header include tree.
> * Abandon the monolithic build infrastructure.

One would need a more "stand alone" tool for non-header only libraries.
But I presume lots of users would just compile the *.cpp files into
their app or build their own DLL. Ideally, the library package
would/should contain a CMake script to do this.

> * Ban relative use of inter-library dependencies.

I don't think that's possible. But I don't think that's necessary. The
only thing is that a user would need to install the dependent libraries
he needs. One could try to make a tool to do this - but I've argued
that that is a fools errand. Rather than argue that any more. I could
just imagine user does the following:

a) Adds a boost header to his project.
b) "installs" that header as above
c) tries to build his project
d) If something missing - call a) for the missing thing

at the end of that process, he has a minimal subset of boost required to
support his project.

If someone has nothing else to do he could write a tool which does
generates a list of dependencies for a given app as a text file. Then
the user would do most of them in one shot. This would likely be an
minor enhancement of BCP or similar program. But the result would be the

BTW - the user already incorporates non boost libraries into his project
using this same procedure. Ideally any dependency checking tools would
work on these as well.

> * Explicit declaration of inter-library dependencies.

I don't think this is necessary.

> * Strict normalized library layout.

I don't think this should be necessary. But I'm aware that some
libraries don't follow convention regarding header layout. So either
those have to change or the "downloader" tool would have to smart enough
to sort those out. I don't recommend the latter option.

> * Remove, and ban, dependency cycles at the inter-library user consumable
> granularity.

I don't think this is necessary. If one is following a chain of headers
rather than a chain of modules - there are no cycles.

> There's probably more items that I've forgotten above. But this should be
> enough to converse about.

LOL - ya think?

I think you're concept of "modularized boost" is at least broadly
similar to mine.

To summarize, the only things we would need:

a) we need a tool to download/transform one boost library at a time.

b) optionally, it would be nice to have a dependency listing tool. FYI
this is more difficult than it looks since the user doesn't all the
boost libraries on his machine. Such a tool would have to trawl the
boost master on github or some oneline database of headers summaries.

c) There would likely need to be separate directory - boost tools with a
couple of things in it. Some stuff would be moved from boost root to
boost/tools. So the user wouldn't need the root on his machine.

d) A good written explanation for users who want to do this.

What we don't need to do is re-organize current
boost/development/testing etc. This is merely an alternative deployment
concept. Boost developers would not be effected.

That's it. just three or 4 simple things. And no disruption of current

Robert Ramey

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