Date: Tue, 5 Mar 2019 16:14:19 +0000
Header units name (in source code) exactly a header or a header file that can be found by #include. The path to the actual artifact that is loaded is different, since it is a BMI.
— Gaby
> On Mar 5, 2019, at 7:52 AM, Ben Boeckel via Modules <modules_at_lists.isocpp.org> wrote:
>
>> On Tue, Mar 05, 2019 at 15:46:13 +0200, Boris Kolpackov wrote:
>> I agree with Nathan, all these "provides", "logical-provides", etc.,
>> feel unnecessarily elaborate and confusing. In comparison, here is
>> what we have in build2:
>
> See my reply to Nathan for my response to this.
>
>> While this may need to be extended to support partitions, it suggest a
>> couple of things your description is missing that we found useful:
>
> My code in CMake doesn't care about this. About the only difference
> between modules and non-modules is whether they have a `provides` field.
> That is then handled later when we write out the Ninja and modmap files
> and non-modules just drop out gracefully.
>
>> 1. Translation unit type (module interface, module implementation,
>> or non-modular).
>
> CMake knows based on the command line it generated. Why would any other
> tool not know? In any case, I wouldn't know what to do with the
> information in the code path CMake deals with this. Or is it as a
> convenience for tools that aren't builders (like static analysis)? Not
> sure that'd work there either since the command line is different
> between header units and non-header units (in GCC) anyways, so one has
> to know ahead of time in the first place.
>
>> 2. Whether import is re-exported.
>
> Why would this matter at all? CMake doesn't care right now. I'll add a
> test case to my sandbox repo for reexporting a module.
>
>> I also assume this does not and is not mean to deal with header
>> modules (I don't believe they can be handled with a pre-scan
>> since they affect the preprocessor).
>
> Header modules are supported by this format as well (but CMake needs
> syntax updates for it, so is currently unrealized). The scan can find
> headers using the same logic as it would for #include. The
> implementation may be more involved though. I don't know.
>
> --Ben
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&data=02%7C01%7Cgdr%40microsoft.com%7C3915dc563d674158ca0608d6a1829dc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873979707124400&sdata=q2k9ekbuRzUPkaJOvqhEVu1QGkC4opPjCgrXetfoy2g%3D&reserved=0
> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0144.php&data=02%7C01%7Cgdr%40microsoft.com%7C3915dc563d674158ca0608d6a1829dc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873979707124400&sdata=QAUvp2XrL1F%2Bki6nTpfkNgNhC1g6KbiITwvdol7UEfU%3D&reserved=0
— Gaby
> On Mar 5, 2019, at 7:52 AM, Ben Boeckel via Modules <modules_at_lists.isocpp.org> wrote:
>
>> On Tue, Mar 05, 2019 at 15:46:13 +0200, Boris Kolpackov wrote:
>> I agree with Nathan, all these "provides", "logical-provides", etc.,
>> feel unnecessarily elaborate and confusing. In comparison, here is
>> what we have in build2:
>
> See my reply to Nathan for my response to this.
>
>> While this may need to be extended to support partitions, it suggest a
>> couple of things your description is missing that we found useful:
>
> My code in CMake doesn't care about this. About the only difference
> between modules and non-modules is whether they have a `provides` field.
> That is then handled later when we write out the Ninja and modmap files
> and non-modules just drop out gracefully.
>
>> 1. Translation unit type (module interface, module implementation,
>> or non-modular).
>
> CMake knows based on the command line it generated. Why would any other
> tool not know? In any case, I wouldn't know what to do with the
> information in the code path CMake deals with this. Or is it as a
> convenience for tools that aren't builders (like static analysis)? Not
> sure that'd work there either since the command line is different
> between header units and non-header units (in GCC) anyways, so one has
> to know ahead of time in the first place.
>
>> 2. Whether import is re-exported.
>
> Why would this matter at all? CMake doesn't care right now. I'll add a
> test case to my sandbox repo for reexporting a module.
>
>> I also assume this does not and is not mean to deal with header
>> modules (I don't believe they can be handled with a pre-scan
>> since they affect the preprocessor).
>
> Header modules are supported by this format as well (but CMake needs
> syntax updates for it, so is currently unrealized). The scan can find
> headers using the same logic as it would for #include. The
> implementation may be more involved though. I don't know.
>
> --Ben
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&data=02%7C01%7Cgdr%40microsoft.com%7C3915dc563d674158ca0608d6a1829dc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873979707124400&sdata=q2k9ekbuRzUPkaJOvqhEVu1QGkC4opPjCgrXetfoy2g%3D&reserved=0
> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0144.php&data=02%7C01%7Cgdr%40microsoft.com%7C3915dc563d674158ca0608d6a1829dc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873979707124400&sdata=QAUvp2XrL1F%2Bki6nTpfkNgNhC1g6KbiITwvdol7UEfU%3D&reserved=0
Received on 2019-03-05 17:14:23