Hello, I have been involved in the conversations in the ISO WG21 (C++) SG15 (Tooling Study Group). Particularly in the context of trying to get a story straight on how C++ modules will interact with package managers.
Over the past two months, I have released a couple[1] papers[2], trying to outline the requirements on how C++ modules could be consumed in non-monorepo environments. Particularly, I think that affects how GNU/Linux distributions will have to deal with C++. During early discussion in the SG15 mailing list[3], it became clear that some folks are interested in getting a bit further in the package management side. During cppcon last week I managed to sit down with some of those folks, and got to an agreement to explore the possibility of moving the C++ language a bit ahead in the package management space, instead of just "accepting defeat" and making modules behave like headers in the way they are distributed. So I recently started another conversation[4] where I am trying to summarize what are the different requirements on how package managers and build systems need to cooperate in the context of C++. The main thing, however, is that we're not getting a lot of input from folks involved in the package management side. So I'm reaching out to folks that have experience maintaining C++ libraries in Debian -- although, realistically, this applies to C, C++ and Fortran. This is particularly important because the main risk for any conversation in that area is that we can come up with a spec that "doesn't stick". So in a sense, we need to think about this in terms of "here's an additional thing that folks packaging C++ code will need to do in order to make them consumable by other build systems". Do folks think there's space for us to create more interoperability between package managers and build systems? What are the requirements that should drive an effort on that space? Daniel [1]: https://isocpp.org/files/papers/P2409R0.pdf - Although it is written from Bloomberg's perspective, our understanding is that it matches the requirements for most distributions (in fact, bloomberg uses dpkg for its internal libraries deployed as a "partial distribution" into /opt/bb) [2]: https://isocpp.org/files/papers/P2473R0.pdf - This is a "let's make modules look like headers" proposal. [3]: https://lists.isocpp.org/sg15/2021/10/1083.php [4]: https://lists.isocpp.org/sg15/2021/10/1145.php is where I try to summarize things into a coherent document.