> On 25 Nov 2024, at 14:46, Bret Brown via SG15 <sg15_at_[hidden]> wrote:
>
> 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?

AFAIU: the compiler implementers represented (MSVC, clang, GCC) commented that they all have, indeed, have representative mechanisms to do this already (e.g. specifying where ‘/tmp’ is on unix-like systems, and/or specifying the placement of saved intermediate results relative to working directory and/or the object output directory).
>
> If so, this would literally be standardizing existing practice in the conservative case.

+1 (even if it locally maps to a root for a re-expression of the exising flags)

>
> 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!

The example of using this for modular processes likely distracted from the more general utility - since we have implementer’s experience that this (modular use) can be difficult in at least one case, and another implementer stating that it would not be appropriate for their driver to take on that role.

Iain

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