Date: Wed, 27 Nov 2024 15:00:12 +0100
On Wed, Nov 27, 2024 at 2:41 PM Boris Kolpackov <boris_at_[hidden]>
wrote:
> Mathias Stearn via SG15 <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.
>
wrote:
> Mathias Stearn via SG15 <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.
>
Received on 2024-11-27 14:00:25