Thanks for the early feedback and questions.

On Tue, Jun 10, 2025 at 9:20 PM René Ferdinand Rivera Morell via SG15 <
sg15_at_[hidden]> wrote:

> As I will not currently be able to attend, even remotely, the SG15 meeting
> at Sofia. As I'll be asleep during the time it's taking place. I'm
> providing some minimal feedback and questions on P3696R0.
>

I think we could change the time to Tuesday afternoon or last session if
that would make it so you could attend.


> 1. I find it counterproductive to invent new grammars for specification
> files in the ecosystem. As it appears to be the case in [2.1 Module Maps]
> section. Using a simple existing format, like JSON, would make it easier
> for tooling to adopt widely.
>

[2.1] is just explaining how Clang works. [3.1] talks about the format. I
don't propose a specific one in the paper, and json would be fine. I do
discuss keeping the module.modulemap name because it reduces the number of
names Clang needs to stat, which has had measurable overhead for us in the
past.


> 2. It's not clear how tools consume or produce the module maps proposed.
>

For consumers it just tells them if a given header should be treated as a
header unit. For example when scanning a TU the scanner will know to
implement header unit semantics for the preprocessor, and output it as a
dependency, although P1689 does not support this yet. For a build system
like CMake they can be used to determine the possible set of header units
during configure time.

How they are produced is up to the build config system. Some existing
examples:

Xcode automatically generates module maps for Framework targets by
convention. Every header in the Headers folder is combined into a single
header unit. Clang has a feature that makes this behave as if each header
was a separate header unit, but without all the overhead of doing that.

Google uses information from their build config files to generate them. (
https://maskray.me/blog/2022-09-25-layering-check-with-clang has a bit
about this, although Google also uses them for Include What You Use
enforcement).

Generally the c library and c++ standard library are hand written because
they have special cases with headers that have to be textual.

3. It's not clear how this actually solves the problem of header units. But
> that may be from my own inexperience with header units. :-)
>

The two problems with header units are:

1) How to determine if an #include should be treated as the import of a
header unit.
2) How should the header unit be built

This paper solves 1 in a way that is workable for build systems that don't
support dynamic tasks, and the Baseline Compile Command stuff (P2962,
P2898, and I think a few others) solves 2. Technically you don't need the
baseline compile command, but then you end up building duplicate header
units which kills build perf.

4. What ship vehicle within ISO would be intended for this?
>

Given our current options, the primary IS. The lookup rules are the
difficult part for putting in the IS, but it doesn't require defining that
much. Mainly what it means for one input to be adjacent to another.

- Michael Spencer