Re: [boost] To modularize, or not to modularize. What is the plan?

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. 

Right

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.

Check

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

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

Robert Ramey