On Sun, Jan 14, 2024 at 4:54 AM Andrey Semashev via Boost 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

On Sun, Jan 14, 2024 at 8:39 AM Ruben Perez wrote:

...

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.

Does referencing other Boost libs in Jamfiles change? Is /boost/test//boost_test (or whatever other lib) still the way? How can I CI test whether my lib adheres to modular Boost practices?

No (there might be exceptions that I don't remember at the moment). Your example is invalid though. The current reference for that would be something like /boost/test//boost_unit_test_framework (or other targets based on what you are using). -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On Sun, Jan 14, 2024 at 9:02 AM Ruben Perez wrote:

...

...

Does referencing other Boost libs in Jamfiles change? Is /boost/test//boost_test (or whatever other lib) still the way? How can I CI test whether my lib adheres to modular Boost practices?

No (there might be exceptions that I don't remember at the moment). Your example is invalid though. The current reference for that would be something like /boost/test//boost_unit_test_framework (or other targets based on what you are using).

I wrote that from the top of my head. My point was the target structure.

I suspected that was the case, but wasn't sure. :-) Interestingly though is that technically the references will change. As with the modular setup *all* libraries will need a target to reference when used. And many, many, header only libraries do not have such targets. Adding those targets will be a big chunk of the PRs I will submit. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On 1/14/24 8:11 AM, René Ferdinand Rivera Morell via Boost wrote:

PS. For reference here's a GitHb project that tracks the work https://github.com/users/grafikrobot/projects/1.

Very impressive effort!! I'm sure this has turned into a lot more work than it started out to be. Thanks for addressing all my questions in a constructive way in a post packed with useful information. Robert Ramey

On Mon, Jan 15, 2024 at 4:48 AM Boris Kolpackov wrote:

Just to confirm, the changes that you are proposing will be backwards- compatible from the user's perspective, right? In particular, the public header inclusion paths will still be rather than, say, , correct?

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

On Tue, Jan 16, 2024 at 6:49 PM Peter Turcan via Boost wrote:

This seems like good information to go in the Boost FAQ.

In terms of publicity, "Modular Boost" should be prominently featured in the Table of Contents in the side navigation :) Thanks