In discussion, I recall that it was stated that many (all?) toolchains all
have some form of a directory specification option. Is that not the case?

If so, this would literally be standardizing existing practice in the
conservative case.

In the interest of considering compromises, I have a thought. In addition
to the an output directory setting, should we consider an analog of
dependency scanning transparency for these extra output files? At least
eventually? I am thinking something similar to P1689 or clang-scan-deps or
GCC's -M flags, but including ancillary and implicit output files.

I am for some sort of support in this regard, keeping in mind that we want
to minimize maintenance and adoption burdens as much as possible. It is not
more affordable to underspecify how these tools should interact -- on the
contrary!

Bret

On Mon, Nov 25, 2024, 13:29 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:

> 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.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>