Date: Sat, 1 Sep 2018 00:12:02 +0000
Your characterization of my view is right on target :-)
— Gaby
> On Aug 31, 2018, at 12:14 PM, Tom Honermann <tom_at_honermann.net> wrote:
>
>> On 08/31/2018 02:14 PM, Nathan Sidwell wrote:
>>> On 08/31/2018 12:05 PM, Tom Honermann wrote:
>>>
>>> If so, my concern with that approach is that it effectively requires a build system.
>>
>> Let me clarify something here, it provides mechanism without policy, so yes, it requires something to give the policy. That is a build system. What we're discussing here is a build system -- how things get built. #includes and their include path are a build system in that respect.
>
> I both agree and disagree :)
>
> Gaby has lobbied (and I hope he doesn't have to correct me here) for a distinction between build system and environment setup. Where to draw the line between the two is not clear to me, but perhaps an analogy might help. I suspect we could agree that a compilation database (like the one described at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FJSONCompilationDatabase.html&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=8ZbKOVoCZ632G%2F4zbgCPHJR%2FKxyTW2SwUjaSvJJocxE%3D&reserved=0) is not a build system. But, such a database may be consumed by a build system. In the consumption context, the compilation database is more of a meta-build thing. What I'm lobbying for is a defacto standard way of encoding information needed to resolve module imports that can be consumed by any number of build systems. If we could also use such a system to encode additional requirements for more traditional uses (e.g., general include paths, macro definitions, language dialect requirements), that could be a win too.
>
>> What the mapper does is decouple the compiler from whatever that build system is. (Unlike #include paths, which are baked into compilers.)
>
> And that is a good and useful thing.
>
> Tom.
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=E7C8kaKaHBcNWwOeZEqZhA2zJklCAlCT5f7QzaP44RA%3D&reserved=0
> Link to this post: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2018%2F08%2F5722.php&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=jI8mtis9%2FqJVQNXN2sA6CBsTBa8PfK5EmkI%2B3M1ShVM%3D&reserved=0
— Gaby
> On Aug 31, 2018, at 12:14 PM, Tom Honermann <tom_at_honermann.net> wrote:
>
>> On 08/31/2018 02:14 PM, Nathan Sidwell wrote:
>>> On 08/31/2018 12:05 PM, Tom Honermann wrote:
>>>
>>> If so, my concern with that approach is that it effectively requires a build system.
>>
>> Let me clarify something here, it provides mechanism without policy, so yes, it requires something to give the policy. That is a build system. What we're discussing here is a build system -- how things get built. #includes and their include path are a build system in that respect.
>
> I both agree and disagree :)
>
> Gaby has lobbied (and I hope he doesn't have to correct me here) for a distinction between build system and environment setup. Where to draw the line between the two is not clear to me, but perhaps an analogy might help. I suspect we could agree that a compilation database (like the one described at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FJSONCompilationDatabase.html&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=8ZbKOVoCZ632G%2F4zbgCPHJR%2FKxyTW2SwUjaSvJJocxE%3D&reserved=0) is not a build system. But, such a database may be consumed by a build system. In the consumption context, the compilation database is more of a meta-build thing. What I'm lobbying for is a defacto standard way of encoding information needed to resolve module imports that can be consumed by any number of build systems. If we could also use such a system to encode additional requirements for more traditional uses (e.g., general include paths, macro definitions, language dialect requirements), that could be a win too.
>
>> What the mapper does is decouple the compiler from whatever that build system is. (Unlike #include paths, which are baked into compilers.)
>
> And that is a good and useful thing.
>
> Tom.
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=E7C8kaKaHBcNWwOeZEqZhA2zJklCAlCT5f7QzaP44RA%3D&reserved=0
> Link to this post: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2018%2F08%2F5722.php&data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&sdata=jI8mtis9%2FqJVQNXN2sA6CBsTBa8PfK5EmkI%2B3M1ShVM%3D&reserved=0
Received on 2018-09-01 02:12:06