Date: Fri, 8 Feb 2019 18:30:31 +0100
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]> 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]>
> *Sent:* Friday, February 8, 2019 9:18 AM
> *To:* Evolution Working Group mailing list <ext_at_[hidden]>
> *Cc:* ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <
> tooling_at_[hidden]>; Gabriel Dos Reis <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]>
> 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_[hidden] <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]>
> | 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876390497&sdata=L7ZPTmCXKH85RsKWcY%2B9LDdyZj5pvc1yDUPyKMnHlvE%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&sdata=AaN44dE%2BTPGemUuYNNcZ34BU48TuqVavbBusc%2BzTR1g%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]
> | 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&sdata=Tp1cNviVwPObjeu9KZHdPMmQ7PyLZ0cp7YkVRqRVOVo%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&sdata=fiMwau40AAli3Peve2N5QsogDawYHvMQI9nYYp9jOwk%3D&reserved=0>
> %7Cd49f0fb63aac4ce886ff08d68dddd8b0%7C72f988bf86f141af9
> | 1ab2d7cd011db47%7C1%7C1%7C636852381303060160&sdata=YLene6t
> | qdjuV7ad%2BAHf5kceett%2F1Whqj7Db0zka470g%3D&reserved=0
> _______________________________________________
> Ext mailing list
> 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&sdata=toDBF8LGJcMAW3EI%2FlAd%2FiqS1ZR3XcB3sfDDnYgxDx0%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876420478&sdata=JWYcKaPE4HXfpz5PBmfOeAPYGlzRTF0uv3bTINwZQzA%3D&reserved=0>
>
>
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]> 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]>
> *Sent:* Friday, February 8, 2019 9:18 AM
> *To:* Evolution Working Group mailing list <ext_at_[hidden]>
> *Cc:* ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <
> tooling_at_[hidden]>; Gabriel Dos Reis <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]>
> 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_[hidden] <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]>
> | 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876390497&sdata=L7ZPTmCXKH85RsKWcY%2B9LDdyZj5pvc1yDUPyKMnHlvE%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&sdata=AaN44dE%2BTPGemUuYNNcZ34BU48TuqVavbBusc%2BzTR1g%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]
> | 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&sdata=Tp1cNviVwPObjeu9KZHdPMmQ7PyLZ0cp7YkVRqRVOVo%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&sdata=fiMwau40AAli3Peve2N5QsogDawYHvMQI9nYYp9jOwk%3D&reserved=0>
> %7Cd49f0fb63aac4ce886ff08d68dddd8b0%7C72f988bf86f141af9
> | 1ab2d7cd011db47%7C1%7C1%7C636852381303060160&sdata=YLene6t
> | qdjuV7ad%2BAHf5kceett%2F1Whqj7Db0zka470g%3D&reserved=0
> _______________________________________________
> Ext mailing list
> 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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&sdata=toDBF8LGJcMAW3EI%2FlAd%2FiqS1ZR3XcB3sfDDnYgxDx0%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%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876420478&sdata=JWYcKaPE4HXfpz5PBmfOeAPYGlzRTF0uv3bTINwZQzA%3D&reserved=0>
>
>
Received on 2019-02-08 18:30:46