Ben Boeckel <ben.boeckel_at_[hidden]> writes:

> { //
> "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.
> }, //
> "requires": [ // Modules names required by this
> "M" // compilation.
> ], //
> "depends": [ // Preprocessor dependency files
> "../path/to/source.cpp", // which affect this scan (so it can
> "/usr/include/stdc-predef.h" // be rerun if necessary).
> ], //
> "version": 0, // The file format version.
> "revision": 1 // The file format revision.
> } //

I agree with Nathan, all these "provides", "logical-provides", etc.,
feel unnecessarily elaborate and confusing. In comparison, here is
what we have in build2:

// Translation unit information.
//
struct module_import
{
  string name;
  bool exported; // True if re-exported (export import M;).
};

using module_imports = vector<module_import>;

struct module_info
{
  string name; // Not empty if a module unit.
  bool iface = false; // True if a module interface unit.
  module_imports imports; // Imported modules.
};

enum class translation_type {plain, module_iface, module_impl};

struct translation_unit
{
  module_info mod;

  translation_type
  type () const
  {
    return (mod.name.empty () ? translation_type::plain :
            mod.iface ? translation_type::module_iface
            : translation_type::module_impl);
  }
};

While this may need to be extended to support partitions, it suggest a
couple of things your description is missing that we found useful:

1. Translation unit type (module interface, module implementation,
   or non-modular).

2. Whether import is re-exported.

I also assume this does not and is not mean to deal with header
modules (I don't believe they can be handled with a pre-scan
since they affect the preprocessor).