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.