On Tue, Oct 21, 2025 at 01:28:30 +1100, Russell Shaw wrote:
> I know how to compile with gnu g++23 modules.
>
> What's the first thing i should add to autotools ?
There has been discussion before on the list:
https://lists.gnu.org/archive/html/autoconf/2025-02/msg00000.html
I believe there is significant work to implement the "collation"
mechanism from CMake's strategy (for really reliable modules support;
there are various plateaus that may be preferred before that, but where
to land is for the autoconf developers to decide).
I think the first thing to do is to decide what level of support is
desired (not an exhaustive list):
- "just make it work" MVP: let the compiler do as much work as
possible. Lots of implicit state, so incremental builds may be dirty
and hard to make reliable. Still needs autoconf support for things
like `.pc` file information (which also needs ecosystem-wide
discussion for how to represent reliably) and installation.
- "modules exist": autoconf/automake understand modules and their
content-based dependency discovery and what rules exist. This gets
reliable builds, but still needs a proper collation mechanism to
enforce things like "A links to B, so B cannot import A's modules"
which may succeed in incremental builds if modules are not isolated
properly.
- "modules are different": fully explicit build. `autoconf` directs
which files to use for which modules based on the target-level
dependency graph and (optionally) blocking "private" modules to
targets from use outside the module if desired.
Note that this is separate from any work necessary to consume modules
installed by dependent projects. There are papers for describing this
information (CPS [1] or P3286 [2]). I'm not aware of efforts to describe
the information in `.pc` files.
Thanks,
--Ben
[1] https://github.com/cps-org/cps
[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3286r0.pdf
