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

Tom Honermann tom at honermann.net
Fri Aug 31 21:13:58 CEST 2018


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://clang.llvm.org/docs/JSONCompilationDatabase.html) 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.


More information about the Tooling mailing list