Date: Wed, 20 Nov 2024 19:32:39 +0200
Hi
I was asked to send a quick email about this subject that will be
discussed tomorrow (in the morning session presumably).
The basic conceptual idea is that it might make sense to have a
"target specific private directory" to make it easier for compiler
devs to add cool new stuff much more easily.
The build system would create a new directory for each top level
target (Meson and CMake already do this) and would guarantee that each
compiler invocation would have a flag, say,
--target-private-dir=path/to/dir which would be the same for each
target (exe, static lib, shared lib etc). The compiler would then be
allowed to store whatever information it wants in there.
In hallway discussions some use cases have already been discovered:
- easing the use of import std (including compiling an exe that uses
import std with a single, simple command line invocation)
- caching
- writing extra data like -ftime-trace or the fixit data from safety
profile checking
- wilder things like creating a unix socket in the directory so
different compiler processes can talk to each other if they want
- etc
As all of this is internal to the compiler, there is no need to
provide public APIs for anything (so no bw compatibility shackles) and
also that all those features will work with any build system out of
the box as long as it passes said flag to the compiler.
Or that is the dream anyway. Let's have a discussion and see how
things go from there.
I was asked to send a quick email about this subject that will be
discussed tomorrow (in the morning session presumably).
The basic conceptual idea is that it might make sense to have a
"target specific private directory" to make it easier for compiler
devs to add cool new stuff much more easily.
The build system would create a new directory for each top level
target (Meson and CMake already do this) and would guarantee that each
compiler invocation would have a flag, say,
--target-private-dir=path/to/dir which would be the same for each
target (exe, static lib, shared lib etc). The compiler would then be
allowed to store whatever information it wants in there.
In hallway discussions some use cases have already been discovered:
- easing the use of import std (including compiling an exe that uses
import std with a single, simple command line invocation)
- caching
- writing extra data like -ftime-trace or the fixit data from safety
profile checking
- wilder things like creating a unix socket in the directory so
different compiler processes can talk to each other if they want
- etc
As all of this is internal to the compiler, there is no need to
provide public APIs for anything (so no bw compatibility shackles) and
also that all those features will work with any build system out of
the box as long as it passes said flag to the compiler.
Or that is the dream anyway. Let's have a discussion and see how
things go from there.
Received on 2024-11-20 17:32:53