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

My wiki searches have not revealed any recorded minutes for discussion of P1300. The paper is listed in the EWG/EWGI backlog or papers list in the San Diego and Kona 2019 wikis, but I don't see that it was actually discussed, nor do I recall it being discussed (I do recall having read the paper).

I was never given an opportunity to present P0804 (Impact of the modules TS on the C++ tools ecosystem) to EWG. I was able to present it to a small group of EWG participants during a special modules face-to-face meeting held in Seattle in September, 2018. Minutes here. Per the poll, the participants were opposed to spending time during the C++20 development cycle attempting to address tooling related concerns. Personally, I think that group failed to appreciate the technical challenges involved.

This email thread is my attempt to ensure that tooling related concerns for contracts are well understood and that implementation strategies are considered and communicated well before C++26 is finalized.

Tom.

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.
_______________________________________________
SG21 mailing list
SG21@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
Link to this post: http://lists.isocpp.org/sg21/2023/11/5468.php