Date: Mon, 18 Feb 2019 02:33:19 +0000
Agreed. Fewer TLAs lower the burden of entry for discussions, especially if we redefine existing terms for the sake of a TLA.
(TLA is a three letter acronym for three letter acronym 😉)
On Sun, Feb 17, 2019 at 12:10, Gabriel Dos Reis via Ext <ext_at_[hidden]> wrote:
> All - please let stop using 'LHU' or whatever that means.
>
> They are just headers. There is nothing legacy about them.
>
> | -----Original Message-----
> | From: Ext <ext-bounces_at_[hidden]> On Behalf Of Robert Maynard via
> | Ext
> | Sent: Friday, February 8, 2019 12:10 PM
> | To: Ben Boeckel <ben.boeckel_at_[hidden]>; WG21 Tooling Study Group
> | SG15 <tooling_at_[hidden]>
> | Cc: Robert Maynard <robert.maynard_at_[hidden]>; Evolution Working
> | Group mailing list <ext_at_[hidden]>
> | Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules
> | and its applicability to C++
> |
> | Personally I am concerned with the presumption that users of
> | build-systems will understand that correct builds will only occur if
> | they explicitly list LHU's.
> | My expectation is that projects will try to convert over all/most of
> | '#include' to LHU's and give-up when the tooling doesn't support that.
> | I personally would like to see LHU detection/tracking be a well
> | defined problem that is tractable for tools to solve without user
> | intervention.
> |
> | On Fri, Feb 8, 2019 at 3:04 PM Ben Boeckel <ben.boeckel_at_[hidden]>
> | wrote:
> | >
> | > On Fri, Feb 08, 2019 at 16:51:01 +0000, Gabriel Dos Reis 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.
> | >
> | > Sounds good. Some wordsmithing on the language at Kona to help clarify
> | > would be useful (tracking diffs of diffs are fun!).
> | >
> | > > 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.
> | >
> | > If legacy header units must be mentioned explicitly to compilers, then
> | > CMake can just require such information as additional input in its
> | > input. The compiler can also output what files it would implicitly
> | > generate in its output and `collate` figures things out. It is the
> | > silent implicit stuff that's a problem. For the former, build tools can
> | > also just never say anything about legacy header units and the problem
> | > goes away.
> | >
> | > I'll update the paper with this information.
> | >
> | > > 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.
> | >
> | > I'm thinking that the tool mentioned on the Tcon from Apple would be
> | > useful here. On Slack, Michael Spencer mentioned a `clang-scan-deps`
> | > tool which sounds like it could also serve this purpose.
> | >
> | > Thanks,
> | >
> | > --Ben
> | > _______________________________________________
> | > Tooling mailing list
> | > Tooling_at_[hidden]
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> | open-
> | std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40m
> | icrosoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141af
> | 91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=rsIZ0b
> | HOJ60YJa2VQbJ6ysX35tp8UjZTESzRrh%2BeHv0%3D&reserved=0
> | _______________________________________________
> | Ext mailing list
> | Ext_at_[hidden]
> | Subscription:
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40
> | microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141
> | af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=sRf4
> | bJU04DdblP1J81mGpjIgA5ffKed6sM5Aqi0Tujc%3D&reserved=0
> | Link to this post:
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fext%2F2019%2F02%2F8082.php&data=02%7C01%7Cgdr%4
> | 0microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f14
> | 1af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=4NT
> | 3ZIbaGpfiX1Q4j%2FlqAFKVWwmR3cdfVEYZevuj0vg%3D&reserved=0
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]p.org
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2019/02/8156.php
(TLA is a three letter acronym for three letter acronym 😉)
On Sun, Feb 17, 2019 at 12:10, Gabriel Dos Reis via Ext <ext_at_[hidden]> wrote:
> All - please let stop using 'LHU' or whatever that means.
>
> They are just headers. There is nothing legacy about them.
>
> | -----Original Message-----
> | From: Ext <ext-bounces_at_[hidden]> On Behalf Of Robert Maynard via
> | Ext
> | Sent: Friday, February 8, 2019 12:10 PM
> | To: Ben Boeckel <ben.boeckel_at_[hidden]>; WG21 Tooling Study Group
> | SG15 <tooling_at_[hidden]>
> | Cc: Robert Maynard <robert.maynard_at_[hidden]>; Evolution Working
> | Group mailing list <ext_at_[hidden]>
> | Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules
> | and its applicability to C++
> |
> | Personally I am concerned with the presumption that users of
> | build-systems will understand that correct builds will only occur if
> | they explicitly list LHU's.
> | My expectation is that projects will try to convert over all/most of
> | '#include' to LHU's and give-up when the tooling doesn't support that.
> | I personally would like to see LHU detection/tracking be a well
> | defined problem that is tractable for tools to solve without user
> | intervention.
> |
> | On Fri, Feb 8, 2019 at 3:04 PM Ben Boeckel <ben.boeckel_at_[hidden]>
> | wrote:
> | >
> | > On Fri, Feb 08, 2019 at 16:51:01 +0000, Gabriel Dos Reis 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.
> | >
> | > Sounds good. Some wordsmithing on the language at Kona to help clarify
> | > would be useful (tracking diffs of diffs are fun!).
> | >
> | > > 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.
> | >
> | > If legacy header units must be mentioned explicitly to compilers, then
> | > CMake can just require such information as additional input in its
> | > input. The compiler can also output what files it would implicitly
> | > generate in its output and `collate` figures things out. It is the
> | > silent implicit stuff that's a problem. For the former, build tools can
> | > also just never say anything about legacy header units and the problem
> | > goes away.
> | >
> | > I'll update the paper with this information.
> | >
> | > > 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.
> | >
> | > I'm thinking that the tool mentioned on the Tcon from Apple would be
> | > useful here. On Slack, Michael Spencer mentioned a `clang-scan-deps`
> | > tool which sounds like it could also serve this purpose.
> | >
> | > Thanks,
> | >
> | > --Ben
> | > _______________________________________________
> | > Tooling mailing list
> | > Tooling_at_[hidden]
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> | open-
> | std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40m
> | icrosoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141af
> | 91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=rsIZ0b
> | HOJ60YJa2VQbJ6ysX35tp8UjZTESzRrh%2BeHv0%3D&reserved=0
> | _______________________________________________
> | Ext mailing list
> | Ext_at_[hidden]
> | Subscription:
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40
> | microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141
> | af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=sRf4
> | bJU04DdblP1J81mGpjIgA5ffKed6sM5Aqi0Tujc%3D&reserved=0
> | Link to this post:
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is
> | ocpp.org%2Fext%2F2019%2F02%2F8082.php&data=02%7C01%7Cgdr%4
> | 0microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f14
> | 1af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&sdata=4NT
> | 3ZIbaGpfiX1Q4j%2FlqAFKVWwmR3cdfVEYZevuj0vg%3D&reserved=0
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]p.org
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2019/02/8156.php
Received on 2019-02-18 03:33:25