On Tue, Feb 18, 2025 at 16:32:37 -0500, Zack Weinberg wrote:
> On Tue, Feb 18, 2025, at 8:39 AM, Christoph Grüninger via Discussion list for the autoconf build system wrote:
> > I am interested in the state and plans for supporting C++20 modules.
I am as well. I had actually started drafting an email right to Zack but
then thought better of it and saw this thread conveniently already
started :) . I'd have shown up back in 2019 or so, but Zack (IIRC) had
not yet taken up active maintenance, so I didn't want to ask into the
void. It came up recently on the gcc@ mailing list as well, but I'll
copy a (sorted) timeline of events here for completion's sake:
- 2019 Feb: pushing to get dependency scanning possible (I have patches
to CMake and GCC to proof-of-concept at the Kona meeting)
- 2019 Mar: CMake uses P1689R2 for its Fortran scanning/dependency
computations. The implementation is updated for further revision
updates as time goes on.
- 2019 Apr: Patches to `ninja` land to support `dyndep` (needed for
accurate C++ dependency scanning)
- 2020 Jan: `ninja` 1.10 releases with `dyndep` support
- 2020-2022: hammering out P1689 details. As of P1689R5 it is in a place
where everyone is happy. Alas, my allocations did not align with
faster progress here.
- 2022 Jun: experimental support for named modules lands in CMake 3.25.
Community and toolchain implementers experiment with my GCC patches
and report issues.
- 2022 Nov: VS 17.4 releases with P1689 support
- 2023 Feb: clang-scan-deps learns to write P1689R5
- 2023 Sep: my P1689R5 patches land in GCC
- 2023 Oct: CMake 3.28 releases with named imports as a non-experimental
feature
- 2024 Apr: Support for clang/libc++ and MSVC/STL `import std;` lands in
CMake `master`
- 2024 Jul: Experimental support for `import std;` in CMake 3.30.
- 2024 Nov: Support for GCC's `import std;` lands
> As far as I know, nobody is currently working on anything related to C++
> 2020 in either Autoconf or Automake.
>
> I have not kept up with the evolution of the C++ language since the 2011
> standard, and in particular I know absolutely nothing about the C++2020
> modules feature. So what follows is necessarily very speculative.
This paper I presented to ISO C++ at Kona 2019 is probably helpful:
https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html
It goes over how CMake implements Fortran support in terms of the build
graph. Note that this is the "explicit" build where module dependencies
are dynamically discovered at build time and edges added as a result of
that. There is the "implicit" build where module outputs are just dumped
to a directory and things "find" them there, but this has numerous
drawback that I don't believe it is worth it to implement. I can give
more details if wanted, just don't want to distract here.
Here is the paper for P1689:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html
It is a versioned JSON document with the required information to build
modules correctly (Fortran and C++).
The basic thing that automake would need to provide is a "collator" that
takes:
- the P1689 results from the scanned sources
- output of any dependent library collations (to import modules from its
sources)
- a description of the sources that have been scanned
and generates:
- per-source module dependency information (`-fmodule-mapper=` content
for GCC)
- collation output summarizing module info for libraries linking to this
one
- install rules for modules (as necessary)
- dependency information for `make` so that compilations happen in the
right order
CMake also has the concept of "private" and "public" sources and it also
enforces that modules from "private" sources are not installed or
required by "public" source modules.
> 0) According to your "arewemodulesyet" site, neither GCC nor Clang fully
> supports modules yet, so I would suggest that developer effort is
> best spent there *first.* Autotools probably *shouldn't* try to do
> much of anything with incompletely implemented language features;
> we've had bad luck with that in the past.
That's no reason to not start working on build system support. We (the
C++ community) are at a point that, I believe, is ready for more serious
experimentation with C++ modules by users. However, if their build
systems don't support it, they're kind of out in the cold. So beyond the
"does the syntax work", the first steps involved getting build systems
fed with the requisite information to stitch together the dependencies
at build time. This was P1689 which is implemented in the major
compilers as of its R5. Now that this and `import std` has been done in
the implementations, I believe that there should now be focus on:
- experimenting with modules to gather data on whether "big" or "small"
modules make more sense for a given project
- discovering bugs in the implementations; they'll never be able to get
100% coverage without crowdsourcing it
Of course, actually dealing with modules across the ecosystem will take
time as the minimum required compiler, build tools, etc. will take time
to be accepted *as* minimums. They'll also creep up after that as
showstopper bugs get fixed.
> 1) Autoconf includes logic to probe for various compiler features and
> for adequate support for various levels of the C and C++ standards.
> These probes have a bunch of problems and they currently don't
> include anything newer than about 2017 for either C or C++. I would
> be glad to see work done on fixing these probes' problems and on
> updating them to include the newest editions of the language
> standards. However, the biggest problem with them is NOT that they
> are out of date, but that they do not allow the package being
> configured to declare which edition of the language standard they
> want. That needs to be addressed *before* we add any more editions,
> because the current behavior of selecting the most recent edition the
> compiler supports is known to be troublesome for big important things
> like Postgres, and we don't want to make it worse.
I don't think it makes much sense to probe, at configure time, compiler
features. Certainly not by default. C++ has been pretty good about
getting the information exposed via feature macros for projects that
really want to be flexible around them.
> If you're interested in working on this yourself, or you know someone
> who is, I would be happy to go into more detail. As things stand,
> if nobody steps up to do the work, it is unlikely to get done soon.
>
> 2) Besides an "is this feature available" probe, I don't know if any
> support for C++ 2020 modules is even *necessary*, because I don't
> know how they work. If any other changes are necessary, they would
> probably need to happen in Automake and Libtool, not in Autoconf.
Yes, it is necessary. The build system has to take an active role in the
build to "wire up" dynamic dependencies during the build. I mean, one
*could* do it at `autoconf` time, but that means that any time a file
which *may* contain modules changes, the build graph needs regenerated.
Happy to help,
--Ben
