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