Date: Sun, 17 Feb 2019 22:10:50 +0000
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
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
Received on 2019-02-17 23:10:56