On Tue, Mar 05, 2019 at 07:27:59 -0500, Nathan Sidwell wrote:
> On 3/4/19 5:57 PM, Ben Boeckel via Modules wrote:
> > For CMake support for C++ modules, I've patched GCC so it outputs
> > dependency information in a JSON format. Before going too far down this
>
> Ben's working through the assignment process, which is blocking
> submission to GCC's module branch.

Well, this discussion means that there will likely be changes before
my patch goes anywhere anyways :) .

> > road, I'd like to get feedback on the format. This is for the purposes
> > of being able to implement D1483R1[1] without requiring build tools to
> > implement a C++ parser and instead have the compiler do the "scan" step
> > described there.
> >
> > { //
> > "outputs": [ // Files to be output for this
> > "source.o" // compilation[2].
> > ], //
> > "provides": [ // BMI files provided by this
> > "I.gcm" // compilation.
> > ], //
> > "logical-provides": { // Mapping of module names provided
> > "I": "I.gcm" // to provided BMI files.
> > }, //
>
> The separation of provides and logical-provides seems confusing, at
> least at first blush. Both 'provides' and 'outputs' are outputs the
> compilation provides. Perhaps either subclass 'outputs', which could
> future-proof this, or rename to say 'code' and 'exports'?
>
> "provides": [ "source.o" {"module": "I"} {"bmi": "I.gcm"} ]

There may be other output files (.pdb, .dwo, etc.) that are never
mirrored in a "requires" field, so I think they should stay separate.

> > "requires": [ // Modules names required by this
> > "M" // compilation.
> > ], //
>
> IIRC this is the set of direct imports, not the transitive set. (it's
> easy to change). Which is better? Do they need to be distinguished?
>
> > "depends": [ // Preprocessor dependency files
> > "../path/to/source.cpp", // which affect this scan (so it can
> > "/usr/include/stdc-predef.h" // be rerun if necessary).
> > ], //
>
> NIT: 'requires' and 'depends' are both sets of dependencies and/or
> requirements. Perhaps 'imports' and 'headers' would be more direct names?
> "imports": [ "M" ]
> "headers": [ "../path/to/source.cpp" "/usr/include/stdc-predef.h" ]
> "resources": [ "When std::embed goes live" ]

So the difference here is that imports are required to exist before
compilation starts (modules). Depends can be discovered during
compilation (includes). A subtle difference. I'm fine with finding
synonyms, but they should be kept different. `std::embed` is a
"depends".

We can bikeshed names, but how about `module-imports` and
`compile-depends` instead for now?

Also, this should not be C++ specific…I think the same overall format
can be used for Fortran as well.

> I recommend version == 0 at such an early stage.

Yes, once I make the next round for the patch, this will be fixed (as
well as adding `revision`.

> > - Are there any constraints which should be added to make it even
> > easier for build tools to parse/interpret this format?
>
> You're using JSON, pick a version of that spec and stick with it. Don't
> create yet another variant.

I meant contraints in the semantic information, not the syntax.

--Ben