[Tooling] [Ext] Modules and tooling: Resolving module import declarations

Gabriel Dos Reis gdr at microsoft.com
Sat Sep 1 02:12:02 CEST 2018


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&amp;data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&amp;sdata=8ZbKOVoCZ632G%2F4zbgCPHJR%2FKxyTW2SwUjaSvJJocxE%3D&amp;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 lists.isocpp.org
> Subscription: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&amp;data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&amp;sdata=E7C8kaKaHBcNWwOeZEqZhA2zJklCAlCT5f7QzaP44RA%3D&amp;reserved=0
> Link to this post: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2018%2F08%2F5722.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7Cee5f8863d2f74ffa7ad408d60f75eabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636713396460717221&amp;sdata=jI8mtis9%2FqJVQNXN2sA6CBsTBa8PfK5EmkI%2B3M1ShVM%3D&amp;reserved=0


More information about the Tooling mailing list