Re: Making Boost modular. IMPORTANT! URGENT! <insert-superlative-here>!

From: René Ferdinand Rivera Morell (grafikrobot_at_[hidden])
Date: 2024-01-14 14:46:04

On Sun, Jan 14, 2024 at 4:54 AM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
>
> On 1/14/24 08:41, René Ferdinand Rivera Morell via Boost wrote:
> > Dear fellow Boost authors,
> >
> > As some of you may have heard.. Some of us have been working on making
> > it possible to fully consume Boost in a modular arrangement. First
> > some FAQs about this:
> >
> > Q: What is a "modular arrangement"?
> > A: It's when the libraries can be used, and hence built, without
> > creating the monolithic headers, without needing the root build files,
> > and without needing the libraries to be arranged in the usual
> > root/libs/<name>.
> >
> > Q: Will a modular Boost remove the Boost release?
> > A: No. The collection of libraries is still a single release. See
> > recent discussions about this.
> >
> > Q: Will this change the testing?
> > A: No, unless you want to. You will still be able to test the same
> > non-modular way. But you could also test the modular way.
> >
> > Q: Will this require that we change the current Boost source structure?
> > A: Yes. Unfortunately there is one restriction that adhering to a
> > modular Boost requires. We would not allow sublibs. That is, that we
> > can't support having libraries in root/libs/thing/<library> style
> > locations. All libraries must be single libraries under the root/libs
> > directory. Thankfully there's only a handful of such libraries. The
> > root/libs/numeric/* group of libraries.
>
> Just out of curiosity. Above you're saying that the "modular" Boost will
> not require the root/libs/<name> structure, and yet the
> root/libs/thing/<library> arrangement is a problem. Could you elaborate why?

That requirement, which will become obvious in future PRs, comes from
supporting an automatic/easy way to discover references to Boost libs
once the modular changes to the Jamroot file are done. Okay, that
doesn't really say anything useful. Let me clarify.. Currently the
Jamroot "includes" each of the Boost libraries by searching the libs/*
and libs/*/* locations (doing a glob and loop). That search will no
longer exist. Instead the Jamroot file will contain a single
"project-search /boost : libs ;". With that a reference to a boost lib
(/boost/predef) will search in the "libs" location for it. Now, it's
technically possible to instead do a "project-search /boost : libs
libs/numeric ;". But if there is no Jamroot, i.e. there's no
super-project, and that search declaration is in a user-config.jam (or
equivalent) it means communicating that to users. I.e. it's just
easier on everyone if we adopt a flat hierarchy.

> Also, how will the "monolithic" Boost work if there is no
> root/libs/<name> structure? Or is the structure still required for the
> "monolithic" Boost?

The structure is still required for things like testing and
documentation building. I.e. for release management. As those scripts
do file globbing to figure out what they are doing.

-- 
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net