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: Gavin Lambert (boost_at_[hidden])
Date: 2019-05-07 03:31:36

On 7/05/2019 13:16, Robert Ramey wrote:
> 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.

The problem with this algorithm is when (c) works when it shouldn't, 
because it found another version of the library somewhere else that 
happens to sufficiently resemble the version of the library that was 
actually intended.

This can lead to weird runtime behaviour, mysterious future compilation 
failures, or "it works for me" but not someone else.  The latter two 
should hopefully lead to discovery of the problem eventually, but the 
first can be quite dangerous.

> To summarize, the only things we would need:
> 
> a) we need a tool to download/transform one boost library at a time.

Transform in what way?

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

Most compilers can generate a list of all the headers included by a C++ 
file, recursively.  (And so can boostdep.)  The trick is that there are 
optional dependencies so you kinda have to start with what the user app 
is actually including on a header-by-header basis rather than a 
whole-library basis.

Or at least when declaring whole-library-level dependencies it should 
only consider dependencies included (recursively) by the top-level 
convenience header file, and not those included by optional extra files, 
unless the app actually uses them.

If a header is not found or if an obviously-Boost-library header file is 
found outside of the Boost library root, it probably needs to be downloaded.

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

I don't see why it would need to be any more complex than downloading 
the existing Boost superproject root and doing the equivalent of "git 
submodule update --init" on only the specified submodules, then running 
a b2 build/stage cycle (modified to cope with missing modules).

Either by actually using git, or doing some equivalent with tarball/zip 
snapshots.