Jussi Pakkanen <jpakkane_at_[hidden]> writes:

> The proposal does _not_ require compilers to do anything. [...]

Sure, but quite a few motivating examples that you have listed
(import std, caching) would require synchronization between
compiler instances so I am just pointing out that prior experience
on that is negative.


> it is the build system's responsibility to give each top level target
> its unique dir and pass compiler flags accordingly

Can you define what is a top-level target? For example, is a utility
library, which is used to build a number of libraries/executables
a top-level target?

Also, what happens if the same object file is used as input to build
multiple, say, executables? Who is its top-level target?


> Now we want to write some auxiliary data for each compilation like
> Sarif information. If the output file is `foobar.o` then the compiler
> knows that writing Sarif info to a file named, say, `foobar.o.sarif`
> is both completely safe and does not leave any trash files on the
> user's file system

It is also opaque to the build system. For instance, the build system
won't be able to detect that some of those outputs are missing.

I tend to agree with Gaby, this looks like shifting some of the
responsibility from the build system to the compiler and the user.
I appreciate the short term gain (one can produce extra info without
having to touch the build system or the project's build files), but
I think there will also be long term pain that inevitably comes when
the build system doesn't have the complete view of the build.