Date: Fri, 16 Aug 2019 08:52:18 -0700
I think Gaby's point was that now is a good time to start moving our
sectors of the community to common terminology :)
On Thu, Aug 15, 2019 at 11:31 AM Michael Spencer via SG15
<sg15_at_[hidden]> wrote:
>
> 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 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
sectors of the community to common terminology :)
On Thu, Aug 15, 2019 at 11:31 AM Michael Spencer via SG15
<sg15_at_[hidden]> wrote:
>
> 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 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
-- 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 --
Received on 2019-08-16 10:54:48