I recall the discussions at Kona ending up at "there is no appropriate
venue to discuss this paper in the WG21 committee because it's outside of
their jurisdiction". We sat down at the poolside bar to draft the first
ecosystem TR there and that's I think where the push behind the paper died,
instead focusing on the ecosystem TR (then together with Bryce and Isabella
at the very least).

On Tue, Nov 14, 2023 at 7:04 PM Tom Honermann via SG15 <
sg15_at_[hidden]> wrote:

> On 11/13/23 9:06 AM, Ben Boeckel via SG21 wrote:
>
> 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 <https://wg21.link/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) <https://wg21.link/p0804> 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 <https://wiki.edg.com/bin/view/ModSeattle2018/P0804R0-Sea18>. 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 listSG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2023/11/5468.php
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>