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

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 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 (or ) 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 ) -- is that a dependency or not?

* Strict normalized library layout.

Doesn't this already exist?