[Tooling] Dependency information for module-aware build tools

Boris Kolpackov boris at codesynthesis.com
Tue Mar 5 14:46:13 CET 2019


Ben Boeckel <ben.boeckel at kitware.com> 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).


More information about the Tooling mailing list