Date: Fri, 8 Feb 2019 17:40:34 +0000
Thanks.
Thankfully, the practical problem is less expansive that you might think.
That functionality is modelled after that provided by Clang-Modules.
What that paragraph is saying is that if your programs has a header import of H somewhere, and it also #includes it somewhere, the compiler may reuse the result of building the PCH build for H. Since the build tool is already scanning TUs for dependencies, it will have this information as part of that dependency scan.
Furthermore, whether an implementation actually behaves that way will be documented along with any additional flags. So, you actually only pay (if you pay anything at all) for what you use.
From: Corentin <corentin.jabot_at_[hidden]>
Sent: Friday, February 8, 2019 9:31 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Evolution Working Group mailing list <ext_at_[hidden]cpp.org>; ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules and its applicability to C++
Sorry, Legacy Header Units
Referring specifically to that part of the modules proposal
When a #include appears within non-modular code, if the named header file is known to correspond to a legacy header unit, the implementation treats the #include as an import of the corresponding legacy header unit. The mechanism for discovering this correspondence is left implementation-defined; there are multiple viable strategies here (such as explicitly building legacy header modules and providing them as input to downstream compilations, or introducing accompanying files describing the legacy header structure) and we wish to encourage exploration of this space. An implementation is also permitted to not provide any mapping mechanism, and process each legacy header unit independently
The list of such headers can only be maintained manually or synthesized by scanning the complete dependency tree - rather than be extractable from an arbitrary individual source file.
On Fri, 8 Feb 2019 at 18:20 Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
I cannot understand what you are saying because I don’t know what LHU is, and I don’t understand the second bullet and why that is the case.
From: Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>
Sent: Friday, February 8, 2019 9:18 AM
To: Evolution Working Group mailing list <ext_at_[hidden]socpp.org<mailto:ext_at_[hidden]>>
Cc: ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>; WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>; Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules and its applicability to C++
Nice document.
6.4 I believe LHU imported through include will need to be identified by either
* Having a manually maintained list of LHU
* Parsing all files in the projects/dependency and assuming that files that are not imported with import at least once are not LHU
I agree that letting the compiler decides to treat an include as an LHU without the blessing of the build system would be asking for trouble
On Fri, 8 Feb 2019 at 17:51 Gabriel Dos Reis via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Early feedback regarding section 6.3 and 6.4.
Concern in 6.3:
The description there is notional, not a requirement that needs to be followed by the letter by compilers.
There is an alternative formulation that uses the notion or "semantics abstract graph" (term defined in the Modules TS) that does not rely on synthesized header unit.
Concern in 6.4:
The way to import of "header import" is that of using a precompiled header file. If CMAKE already supports uses of PCHs, then the machinery is already there.
For every import of a header H, there would be a rule for building say H.pch unless there is already a H.pch supplied by the system or other sources.
Early feedback on section 7.
That ask in 7.1 looks immensely reasonable to me; we have been considering similar for a while.
The Visual C++ team would be happy to team up with other tool vendor to provide an open source version.
-- Gaby
| -----Original Message-----
| From: tooling-bounces_at_open-std.org<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On
| Behalf Of Ben Boeckel
| Sent: Friday, February 8, 2019 7:55 AM
| To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
| Subject: [Tooling] [D1483] How CMake supports Fortran modules and its
| applicability to C++
|
| Hi,
|
| Here is copy of Kitware's paper to be discussed at Kona. I have a PDF,
| but it was too large to attach to the list. I'll be at Kona, but the
| other authors are not able to make it.
|
| An HTML version is hosted here:
|
|
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmath
| stuf.fedorapeople.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstuf.fedorapeople.org&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476031606&sdata=sdcGYesC3%2BaYjPOeCMQG%2FcQMrCtQQL4KN%2ByHO1qmVF0%3D&reserved=0>%2Ffortran-modules%2Ffortran-
| modules.html&data=02%7C01%7Cgdr%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476041600&sdata=5cpB36E0IUQwlSNCyIryo2lUg2kFNr3Ba2NS1AfSoSU%3D&reserved=0>%7Cd49f0fb63
| aac4ce886ff08d68dddd8b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
| C1%7C636852381303060160&sdata=ltkTtPf84tUk76Am5swiz6eNBGqZW
| ydRfDoswsYEmlA%3D&reserved=0
|
| Feedback welcome.
|
| Thanks,
|
| --Ben
| _______________________________________________
| Tooling mailing list
| Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
| open-
| std.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstd.org&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476041600&sdata=dWfpP0zlpN5QmBc0PYuWju87u3YUibgsuAs%2FgbdAUTI%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40m
| icrosoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ficrosoft.com&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476051594&sdata=9dHnkp8BLWEOZb3ey5PYBV1OzQ4VxW2Pb6Q%2BVcULURw%3D&reserved=0>%7Cd49f0fb63aac4ce886ff08d68dddd8b0%7C72f988bf86f141af9
| 1ab2d7cd011db47%7C1%7C1%7C636852381303060160&sdata=YLene6t
| qdjuV7ad%2BAHf5kceett%2F1Whqj7Db0zka470g%3D&reserved=0
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]>
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476051594&sdata=JdpROamOqPZ5%2B7DaJD6CsHe%2BOQtl20ZQJwhbBfFr0yY%3D&reserved=0>
Link to this post: http://lists.isocpp.org/ext/2019/02/7507.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2019%2F02%2F7507.php&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476061590&sdata=nj%2BUYjkEtQc1zzi0MNucFK1YFV84wUZ83JERG7Jw8oA%3D&reserved=0>
Thankfully, the practical problem is less expansive that you might think.
That functionality is modelled after that provided by Clang-Modules.
What that paragraph is saying is that if your programs has a header import of H somewhere, and it also #includes it somewhere, the compiler may reuse the result of building the PCH build for H. Since the build tool is already scanning TUs for dependencies, it will have this information as part of that dependency scan.
Furthermore, whether an implementation actually behaves that way will be documented along with any additional flags. So, you actually only pay (if you pay anything at all) for what you use.
From: Corentin <corentin.jabot_at_[hidden]>
Sent: Friday, February 8, 2019 9:31 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Evolution Working Group mailing list <ext_at_[hidden]cpp.org>; ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules and its applicability to C++
Sorry, Legacy Header Units
Referring specifically to that part of the modules proposal
When a #include appears within non-modular code, if the named header file is known to correspond to a legacy header unit, the implementation treats the #include as an import of the corresponding legacy header unit. The mechanism for discovering this correspondence is left implementation-defined; there are multiple viable strategies here (such as explicitly building legacy header modules and providing them as input to downstream compilations, or introducing accompanying files describing the legacy header structure) and we wish to encourage exploration of this space. An implementation is also permitted to not provide any mapping mechanism, and process each legacy header unit independently
The list of such headers can only be maintained manually or synthesized by scanning the complete dependency tree - rather than be extractable from an arbitrary individual source file.
On Fri, 8 Feb 2019 at 18:20 Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
I cannot understand what you are saying because I don’t know what LHU is, and I don’t understand the second bullet and why that is the case.
From: Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>
Sent: Friday, February 8, 2019 9:18 AM
To: Evolution Working Group mailing list <ext_at_[hidden]socpp.org<mailto:ext_at_[hidden]>>
Cc: ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>; WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>; Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules and its applicability to C++
Nice document.
6.4 I believe LHU imported through include will need to be identified by either
* Having a manually maintained list of LHU
* Parsing all files in the projects/dependency and assuming that files that are not imported with import at least once are not LHU
I agree that letting the compiler decides to treat an include as an LHU without the blessing of the build system would be asking for trouble
On Fri, 8 Feb 2019 at 17:51 Gabriel Dos Reis via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Early feedback regarding section 6.3 and 6.4.
Concern in 6.3:
The description there is notional, not a requirement that needs to be followed by the letter by compilers.
There is an alternative formulation that uses the notion or "semantics abstract graph" (term defined in the Modules TS) that does not rely on synthesized header unit.
Concern in 6.4:
The way to import of "header import" is that of using a precompiled header file. If CMAKE already supports uses of PCHs, then the machinery is already there.
For every import of a header H, there would be a rule for building say H.pch unless there is already a H.pch supplied by the system or other sources.
Early feedback on section 7.
That ask in 7.1 looks immensely reasonable to me; we have been considering similar for a while.
The Visual C++ team would be happy to team up with other tool vendor to provide an open source version.
-- Gaby
| -----Original Message-----
| From: tooling-bounces_at_open-std.org<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On
| Behalf Of Ben Boeckel
| Sent: Friday, February 8, 2019 7:55 AM
| To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
| Subject: [Tooling] [D1483] How CMake supports Fortran modules and its
| applicability to C++
|
| Hi,
|
| Here is copy of Kitware's paper to be discussed at Kona. I have a PDF,
| but it was too large to attach to the list. I'll be at Kona, but the
| other authors are not able to make it.
|
| An HTML version is hosted here:
|
|
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmath
| stuf.fedorapeople.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstuf.fedorapeople.org&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476031606&sdata=sdcGYesC3%2BaYjPOeCMQG%2FcQMrCtQQL4KN%2ByHO1qmVF0%3D&reserved=0>%2Ffortran-modules%2Ffortran-
| modules.html&data=02%7C01%7Cgdr%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476041600&sdata=5cpB36E0IUQwlSNCyIryo2lUg2kFNr3Ba2NS1AfSoSU%3D&reserved=0>%7Cd49f0fb63
| aac4ce886ff08d68dddd8b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
| C1%7C636852381303060160&sdata=ltkTtPf84tUk76Am5swiz6eNBGqZW
| ydRfDoswsYEmlA%3D&reserved=0
|
| Feedback welcome.
|
| Thanks,
|
| --Ben
| _______________________________________________
| Tooling mailing list
| Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
| open-
| std.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstd.org&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476041600&sdata=dWfpP0zlpN5QmBc0PYuWju87u3YUibgsuAs%2FgbdAUTI%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40m
| icrosoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ficrosoft.com&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476051594&sdata=9dHnkp8BLWEOZb3ey5PYBV1OzQ4VxW2Pb6Q%2BVcULURw%3D&reserved=0>%7Cd49f0fb63aac4ce886ff08d68dddd8b0%7C72f988bf86f141af9
| 1ab2d7cd011db47%7C1%7C1%7C636852381303060160&sdata=YLene6t
| qdjuV7ad%2BAHf5kceett%2F1Whqj7Db0zka470g%3D&reserved=0
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]>
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476051594&sdata=JdpROamOqPZ5%2B7DaJD6CsHe%2BOQtl20ZQJwhbBfFr0yY%3D&reserved=0>
Link to this post: http://lists.isocpp.org/ext/2019/02/7507.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2019%2F02%2F7507.php&data=02%7C01%7Cgdr%40microsoft.com%7C0fc75e3276d84674c68108d68deb2876%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852438476061590&sdata=nj%2BUYjkEtQc1zzi0MNucFK1YFV84wUZ83JERG7Jw8oA%3D&reserved=0>
Received on 2019-02-08 18:40:38