On 4/28/22 12:55 PM, Ville Voutilainen wrote:
> On Thu, 28 Apr 2022 at 19:43, Tom Honermann via Ext
> <ext_at_[hidden]> wrote:
>> Anyway, back to Patrice's request. Gaby (and any other implementors), can you explain why having the compiler driver automate these tasks, just for the standard library, would be unreasonable? I think it is worth noting that the MSVC compiler already supports the ability to create some files on demand per the #import directive; the "Header files created by import" section seems particularly related.
> Consider this more a curiosity question rather than a direct answer to
> your question by a seasoned compiler vendor, which I'm not.
> If the compiler can't use an existing build artifact, and needs to
> rebuild one, where is it going to put it? Is the location somehow
> relative to the current source tree (relative how? Where?), specific
> to the current user, something wider than that? Do you want
> to keep it for reuse with other source files and their compilation?

I would put that in the implementation-defined bucket. Clang maintains a
ModuleCache directory for the implicitly built module files it
constructs. Users can specify an alternate directory if they like.

> Answering such questions with a build system in hand seems much more
> reasonable, because build systems are able to do
> all of those things.
I don't agree with the "much more reasonable" characterization. Compiler
drivers recognize options for directories used for many purposes today,
both input and output. I don't see this use case as being any different.
>
> Yes, compilers generate intermediates, but they tend to clean those up
> after their dependent thing is built. They certainly generate
> the final targets, but a standard library module artifact is in some
> ways more like an intermediate, but in various ways perhaps quite
> different.
I agree there are differences, but I don't see those differences posing
challenges that haven't already been solved before; Clang already
handles this.
>
> Also, Gaby didn't seem to oppose the idea of a "new driver" that would
> invoke the plain compiler driver to accomplish this. Should such
> a new wrapper driver appear, I'm not sure we're putting users at a
> disadvantage that we worry about (and yes, I do agree with those
> concerns to a fair extent).

It depends somewhat on what that "new driver" is. If it is something
that is shipped with the compiler such that it doesn't have to be
separately installed and configured for any particular toolchain, that
might be ok. But it probably wouldn't be something that I could just
drop in and use with my existing build systems.

One of the problems I want to avoid is having to teach the many
different build systems that I'm exposed to how to build standard
library modules for all the various standard libraries (and versions
there of). Ad-hoc home grown build systems are likely, in my opinion, to
be a significant road bump to modules adoption if existing implementors
don't provide a transparent implicit build mechanism as was done for
Clang Modules. The implicit build model used for Clang Modules is not
perfect, nor the most efficient, but it has been proved to be deployable
exactly because existing build systems can take advantage of it with no
changes other than perhaps having to pass a '-fmodules' option.

Tom.