Does "all the output go there" imply "anything found there is an output"?

-- Gaby



________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Mathias Stearn via SG15 <sg15_at_[hidden]>
Sent: Wednesday, November 27, 2024 3:00:12 PM
To: Boris Kolpackov <boris_at_[hidden]>
Cc: Mathias Stearn <redbeard0531_at_[hidden]>; Mathias Stearn via SG15 <sg15_at_[hidden]>
Subject: Re: [isocpp-sg15] Compiler private dir discussion thu morning



On Wed, Nov 27, 2024 at 2:41 PM Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>> wrote:
Mathias Stearn via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> writes:

> But this gives a clean way for the compiler to introduce new files
> that the build system doesn't need to care about but are consumed
> by other operations (eg .dwo being used by gdb)

Unless the build system needs to install these .dwo files someplace
where gdb can find them, no?

Shouldn't the build system just leave them exactly where the compiler put them? The compiler inserts a link to that path in the .o, IIUC. IMO .dwo files are only for local development, so installing them is silly. If you are building an artifact to ship, you probably want unfissioned debug info, then splitting debug info out after the final link. But if your build system insists on doing the dance of rolling up the .dwo files into .dwp files (which defeats much of the point of .dwo files in the first place), then it is free to start caring about them.

That doesn't contradict my point that only the things that want or need to care about specific output files needs to know about them. Right now each part of the build system, cleaning, caching, distribution (whether separate tools like ccache/icecream, or integrated into a monolithic build system) needs to be able to guess every output file that a compiler will produce based on a set of arguments. By just having a directory and saying that all outputs go there, most things can stop caring about the individual files. And new files can be added without affecting the correctness of all of those tools. It may be that some files (eg SARIF or compile time profiles) are completely ignored by the whole build process and just shipped around and cached as blobs as needed, then some external actor after the build just scans for all of them (eg to display them in an IDE)


I believe that will be the common theme: first it would seem the
build system doesn't need to care about some outputs (debug info,
SARIF files) but after a moment of reflection one realizes that
there are use-cases where the build system would need to be
involved.