Is there a plan to support C++ Module？

[李智]

GN is a very good tool, but it would be even better if C++ modules were supported

[Dirk Pranke]

Some work has been done on this in the past:

https://gn-review.googlesource.com/c/gn/+/7401

However, it probably is fairly out of date. 

There is also some work going on intermittently in adding modules to Chromium, which would certainly drive us to add whatever we needed to add to GN:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/modules.md

That said, at the moment there's no timeline for this to be done.

-- Dirk

On Mon, Jan 20, 2025 at 1:09 AM 李智 <lzhi...@gmail.com> wrote:

GN is a very good tool, but it would be even better if C++ modules were supported

To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

[Ben Boeckel]

On Mon, Jan 20, 2025 at 11:26:09 -0800, 'Dirk Pranke' via gn-dev wrote:
> Some work has been done on this in the past:
>
> https://gn-review.googlesource.com/c/gn/+/7401
>
> However, it probably is fairly out of date.

Taking a quick peek, this looks to be the Clang-specific modules stuff,
not C++20 modules (i.e., I see no `export module` statements in the
examples added here).

> There is also some work going on intermittently in adding modules to
> Chromium, which would certainly drive us to add whatever we needed to add
> to GN:
>
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/modules.md
>
> That said, at the moment there's no timeline for this to be done.

I followed some links there.

https://gn.issues.chromium.org/issues/40643476#comment8

refers to this post:

https://nibblestew.blogspot.com/2023/10/the-road-to-hell-is-paved-with-good.html

I replied to things here on Reddit:

https://www.reddit.com/r/cpp/comments/17a4t6l/the_road_to_hell_is_paved_with_good_intentions/
(primary rebuttal is https://www.reddit.com/r/cpp/comments/17a4t6l/comment/kqeemic/?context=3
but there is discussion throughout the comments)

In summary, CMake implements things the way it does because of the use
cases expected to be supported. Because CMake is already used
"everywhere" and has no hard-enforced conventions laid down, it is hard
to not be flexible here. But things can be simplified if one is willing
to do things such as:

- expect module names based of filename (and extension)
- not enforce any kind of "module visibility" rules[1]
- per-source flags (uniform flags allows for easier batch scanning)
- use implicit module lookup (though this is likely untenable for
Google given the "doesn't work with remote execution" and "how does
one do caching?" problems this causes)

Though once one supports explicit builds, you're most of the way to what
CMake does anyways…assuming one wants to keep build graph regeneration
out of the "I only edited a source file" feedback loop.

I am a CMake developer, but I am interested in seeing modules adopted
more widely in the ecosystem regardless of buildsystem, so feel free to
tag me on things for high-level review of modules support.

Thanks,

--Ben

[1] CMake matches up modules exactly rather than doing a "everybody
write your module to directory D" and then telling everybody "go look
for modules you need in directory D" because an incremental build could
allow a TU in library A to use a module from library B even though B
links to A.

[Dirk Pranke]

Hi Ben,

Thanks for your feedback. I'll definitely keep it in mind going forward.

You're right that so far we've only really looked at Clang-style modules AFAIK.

-- Dirk