On Mon, May 6, 2019 at 7:13 PM Gavin Lambert via Boost < boost@lists.boost.org> 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
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
(or ) 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
) -- 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