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 00:12:56

On 7/05/2019 11:47, Rene Rivera wrote:
> * Abandon the single header include tree.
> * Abandon the monolithic build infrastructure.

I'm not sure those are strictly necessary, as long as the system can 
cope with a "partial checkout" and can ignore missing submodules.

Removing the single include directory would just break existing code and 
documentation, with not really any particular benefit that I can see?

Though there's a big caveat with missing modules -- if the user does a 
#include <boost/optional.hpp> and Boost.Optional wasn't installed, they 
might get an older Boost.Optional from the OS packages rather than an 
error, which is probably wrong (because mixing versions unintentionally 
is bad).  This argues that instead of omitting header files entirely, 
when a submodule is missing the build process should actually install 
stub headers that #error out ... which means that the build system needs 
to know what header files to create even when the submodule isn't 
installed, which is tricky, *especially* for users in the habit of 
including individual headers from the library rather than a convenience 
composite header.

(And before you suggest that removing the single header directory solves 
this: it doesn't, at least not after the OS packages are updated to the 
new version's include paths as well.)

> * Ban relative use of inter-library dependencies.

I think this is already the case; a library that uses Boost.Config does 
#include <boost/config.hpp> (or <boost/config/...>) rather than anything 
else, for example.  Or do you have some specific counter-examples?

> * Explicit declaration of inter-library dependencies.

This can get a little tricky in some cases, as previously discussed. 
For example, if Optional depends on Serialization only if you include a 
specific header file (which is not included by the default 
<boost/optional.hpp>) -- is that a dependency or not?

> * Strict normalized library layout.

Doesn't this already exist?