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: Rene Rivera (grafikrobot_at_[hidden])
Date: 2019-05-07 03:57:59

On Mon, May 6, 2019 at 7:13 PM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

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

What system are you thinking of? Does it already exist?

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

How would it break existing code? And what code would it break? I ask
because I know for a fact that it doesn't break existing code. As not
having a single include directory works perfectly well with the modular
Conan Boost packages.

> 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 is problem at present even if there are no missing files. This is not
a problem specifically of Boost either. It happens with any C or C++
library. There are software engineering methods and tools designed to deal
with that problem. But having a modular Boost would actually make it easier
to deal with that problem. As we could then include a version header for
each library. And the library could check that the versions of its
dependencies satisfy their requirements and error otherwise.

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

I don't see that as a conclusion.

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

Haha.. didn't even think of it ;-)

> * 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?
>

Oh, yes, I have examples. Examples I've ru across from creating the Conan
modular Boost packages. You made the mistake of thinking only of header
files. There are also source files and build files to consider. Although
currently I can only find one such occurrence. So this seems to have
improved in the past year.

> * 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?
>

It is.

> > * Strict normalized library layout.
>
> Doesn't this already exist?
>

Key word is strict. Some libraries don't follow the current one. And the
current layout is fuzzy in some respects.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net