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.
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