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?

Answering such questions with a build system in hand seems much more
reasonable, because build systems are able to do
all of those things.

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.

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).