On Thu, Nov 09, 2023 at 22:09:55 +0200, Ville Voutilainen via SG15 wrote:
> On Thu, 9 Nov 2023 at 21:58, Tom Honermann via SG21
> > Some regular attendees of SG15 have expressed concerns that a
> > contracts design (the MVP) might be accepted for C++26 without
> > adequate tooling consideration thereby potentially leading to a
> > situation like we have now with modules where we have a language
> > feature with significant adoption challenges. I share some of these
> > concerns.
>
> I would hesitate to suggest or leave room for the impression that
> modules were standardized without adequate tooling consideration.

Well, P1300 was ignored at least (though I didn't search for minutes
related to it, the end result is basically "no effect").

    https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1300r0.pdf

We now have a named module system which is isomorphic to Fortran in
terms of sophistication in the build graph executor[1]. It is more
complicated for build *systems* because Fortran can get away with "this
is the one way this module exists" and not have to curate a BMI variant
per importer potential. C++ is better in implementation because the
compiler can say use *this* BMI instead of having to coordinate with
include path search mechanisms.

The biggest fallout is that modules support is limited to (not complete,
but probably not missing many):

- build2
- CMake
  - VS 2022 17.6+
  - Ninja 1.11.1+
- evoke (?)
- GNU Make (with GCC; Clang has libcody patches out-of-tree)
- llbuild (?)
- MSBuild
- xmake

So we've lost/left behind at least (this is obviously not a
comprehensive list):

- autotools (no idea)
- CMake with any other generator (Makefiles is possible, but needs major
  surgery)
- hand-coded Makefiles
- Meson (aware of the work needed but, AFAIK, not finished)
- qmake
- qubes
- Xcode

There was also a lack of build system implementation experience before
accepting them (I had a set of patches for CMake, GCC, and Ninja at Kona
2019, Boris had a from-the-ground-up build2 system of some vintage
around that time, and that's it I believe). AFAIK, other extant build
systems were not working on them prior to their publication. Of course,
actually trying to land my prototype patches ended up discovering
*further* build system semantics that needed hashed out (mainly around
installation of module sources) before they could truly be handed off to
C++ developers.

> Furthermore, some new language facilities just do have adoption
> challenges, that's sometimes the nature of the beast. The
> tooling-feedback
> from e.g. build system developers hasn't thus far revealed a need to
> do major design surgery to modules, as far as I have understood.

It's mainly been grammar tweaks (e.g., disallowing macro expansion for
the key parts of `export module foo;` to avoid…shenanigans). Other than
that, suggestions always hit the "what is a file?" limitations of the
language standard. Also, if tooling had their way, I suspect header
units would be…different. We also have expanded the venerable zoo of
extensions that are considered "C++" code:

    C M c++ cc cpp cxx m mm mpp CPP ixx cppm ccm cxxm c++m
                            ^^^ ^^^ ^^^^ ^^^ ^^^^ ^^^^

I've highlighted the new extensions modules has…inspired because the
standard can't give any suggestions here. I've also seen another new
extension last week that someone asked if CMake would support it and I
told them I was going to pretend I didn't see that and asked them to
pick from any of the above existing selections instead.

> Keeping tooling people up to date is always a good idea, of course.

I'd prefer "in the loop" rather than "up to date". Heads up of the "hey,
we sent this to Core, do you have input?" variety feel more
"notification" rather than "collaboration".

--Ben

[1] Sure, Fortran supports multiple modules to be made per source. The
big step is from zero to one, not one to many.