Date: Thu, 15 Aug 2019 11:31:37 -0700
On Tue, Aug 13, 2019 at 9:59 PM Gabriel Dos Reis via SG15 <
sg15_at_[hidden]> wrote:
> 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
>
I used the terms because they have been in widespread use in the clang
community for a while now (and the email was targeted at them), but I agree
that an implicit/explicit build or dependency is a more precise term.
- Michael Spencer
>
> > On Aug 13, 2019, at 1:42 PM, Bryce Adelstein Lelbach aka wash via SG15 <
> sg15_at_[hidden]> 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&data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&sdata=4YSl40KbMUNgkJqXM75dCmxW9%2BBADt%2Bjcfb%2FQI4KmMA%3D&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&data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&sdata=XPfRwmYezT0EdXBTSWnfcCf9lS82YdJ%2FjYYez%2BgRRA4%3D&reserved=0
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
sg15_at_[hidden]> wrote:
> 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
>
I used the terms because they have been in widespread use in the clang
community for a while now (and the email was targeted at them), but I agree
that an implicit/explicit build or dependency is a more precise term.
- Michael Spencer
>
> > On Aug 13, 2019, at 1:42 PM, Bryce Adelstein Lelbach aka wash via SG15 <
> sg15_at_[hidden]> 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&data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&sdata=4YSl40KbMUNgkJqXM75dCmxW9%2BBADt%2Bjcfb%2FQI4KmMA%3D&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&data=02%7C01%7Cgdr%40microsoft.com%7Ce76663c002134498362f08d7202eb61f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013257315122021&sdata=XPfRwmYezT0EdXBTSWnfcCf9lS82YdJ%2FjYYez%2BgRRA4%3D&reserved=0
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2019-08-15 13:33:51