Friendly request: please can we not use the phrases “implicit module” and “explicit module”?

I think the terms ‘implicit’ and ‘explicit’ apply to *build*, not modules themselves.

— Gaby

> On Aug 13, 2019, at 1:42 PM, Bryce Adelstein Lelbach aka wash via SG15 <sg15_at_lists.isocpp.org> wrote:
>
> Michael Spencer will be talking about clang-scan-deps, and this
> (originally posted to the Clang developer's list):
>
> [clang][RFC] C++20 modules dependency discovery
>
> C++20 is coming and we need to decide how clang will handle dependency
> discovery for modules. In the following, module means compiled C++20
> module interface unit, and I will use header unit to refer to the
> thing generated by a clang module map.
>
>
> There are two different modes we care about when it comes to module
> dependencies: implicit and explicit.
>
>
> Implicit Modules
>
> ================
>
>
> For implicit modules the build system doesn’t know anything about
> them, and thus can’t care about any intermediate files. It needs to
> know about all source files that if changed should cause a rebuild of
> this translation unit.
>
>
> For this case clang needs to output the full transitive set of
> dependencies, excluding any intermediate temporaries. This also means
> that we can’t get the full set of dependencies without actually at
> least preprocessing every module transitively referenced. This means
> that -E -MD should fail if it can’t find a module or header unit.
>
>
> Explicit Modules
>
> ================
>
>
> For explicit modules we only need to know the direct dependencies, as
> the build system will handle the transitive set.
>
>
> For preprocessing we still need to import header units (but only their
> preprocessor state), but not normal modules. For this case it’s ok if
> -E -MD fails to find a module. But it does still need to be able to
> find header units and module maps. Additionally the normal Make output
> syntax is not sufficient to represent the needed information unless
> the driver decides how modules and header units should be built and
> where intermediate files should go. There’s currently a json format
> working its way through the tooling subgroup of the standards
> committee that I think we should adopt for this.
>
>
> I think we need separate modes in clang for these along with support
> for scanning through header units without actually building a clang
> module for them. clang-scan-deps will make use of the explicit mode.
> The question I have is how should we select this mode, and what clang
> options do we need to add?
>
>
> Proposal
>
> ========
>
>
> As a rough idea I propose the following:
>
>
> -M? means output the json format which can correctly represent
> dependencies on a module for which we don’t know what the final file
> path will be.
> clang++ -std=c++20 -E -MD -fimplicit-header-units should implicitly
> find header unit sources, but not modules (as we've not given it any
> way to look up how to build modules).
> This means that the dep file will contain a bunch of .hs,
> .modulemaps, and any .pcms explicitly listed on the command line.
> This also means erroring on unknown imported modules as we don't
> know what to put in the dep file for them.
> clang++ -std=c++20 -E -MD -fimplicit-header-units -fimplicit-module-lookup=?
>
> should do the same as the above, except that it does know how to find
> modules, and should list all of the transitive dependencies of any
> modules it finds.
>
> clang++ -std=c++20 -E -MD should fail if it hits a module or header
> unit, and should never do implicit lookup.
> clang++ -std=c++20 -E -M? should scan through header units without
> actually building clang modules for them (to get the macros it needs),
> and should note all module imports.
> This means that the dep file will contain only .hs that it includes,
> and use the json representation of header units and modules.
> It will also be shallow, with only direct dependencies.
>
>
> Additionally, we should (eventually) make:
>
>
> $ clang++ -std=c++20 a.cpp b.cpp c.cpp a.cppm -o program
>
>
> Work without a build system, even in the presence of modules. To do
> this we will need to prescan the files to determine the module
> dependencies between them and then build them in dependency order.
> This does mean adding a (simple) build system to the driver (maybe
> [llbuild](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapple%2Fswift-llbuild&amp;data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&amp;sdata=4YSl40KbMUNgkJqXM75dCmxW9%2BBADt%2Bjcfb%2FQI4KmMA%3D&amp;reserved=0)?), but I think it’s
> worth it to make simple cases simple. It may also make sense to
> actually push this work out to a real build system. For example have
> clang write a temporary ninja file and invoke ninja to perform the
> build.
>
> --
> Bryce Adelstein Lelbach aka wash
> CUDA Core C++ Libraries Lead @ NVIDIA
> ISO C++ Library Evolution Incubator Chair
> ISO C++ Tooling Chair
> CppCon and C++Now Program Chair
> CUDA Convert and Reformed AVX Junkie
>
> Sleep is for the weak
> --
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&amp;sdata=XPfRwmYezT0EdXBTSWnfcCf9lS82YdJ%2FjYYez%2BgRRA4%3D&amp;reserved=0