[Tooling] [isocpp-modules] Dependency information for module-aware build tools

Ben Boeckel ben.boeckel at kitware.com
Tue Mar 5 15:56:01 CET 2019


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


More information about the Tooling mailing list