Date: Mon, 25 Nov 2024 13:07:12 +0200
On Mon, 25 Nov 2024 at 10:32, Boris Kolpackov <boris_at_[hidden]> wrote:
> This was probably brought up during the discussion, but just in
> case: Naturally, the build system will be running multiple compiler
> instances that share such a private directory in parallel. Which
> means that for anything shared there will need to be filesystem-
> based locking/synchronization. It is my understanding this aspect
> made Clang's implicit modules unworkable.
The proposal does _not_ require compilers to do anything. A completely
valid way of implementing a command line argument like, say,
`--target-private-directory foo` is to drop it to the floor or even
say that there is no compiler flag to specify such a thing. The only
thing we care about is agreeing that such a thing conceptually might
exist and which properties it would have (e.g. it is the build
system's responsibility to give each top level target its unique dir
and pass compiler flags accordingly).
Actual usage is a whole different thing. For example let us suppose
that the private dir is the same where intermediate object files go
(which makes sense, most build systems already have a private dir for
exactly this use case). 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 and that running the
equivalent of `ninja clean` would remove said files (it being the
build system's responsibility). Similarly scanning Sarif file outputs
for the whole project is simple: go through all private dirs in the
build dir and look for files with a specific file name.
And just to be sure: this is just an example. I'm _not_ saying this is
how Sarif data _should_ work, just that this is one way that it
_could_ work.
File locking and the like would _only_ come into play if some compiler
vendor, out of their own free will and choice, would think of some
internal scheme for sharing. In that case we could say "great, that
directory is yours to do whatever you want, go nuts". And if they
don't want to do that then we can also say "great, nothing changes,
but the directory is still there for you to output auxiliary data
should you want to do that either now or later".
> This was probably brought up during the discussion, but just in
> case: Naturally, the build system will be running multiple compiler
> instances that share such a private directory in parallel. Which
> means that for anything shared there will need to be filesystem-
> based locking/synchronization. It is my understanding this aspect
> made Clang's implicit modules unworkable.
The proposal does _not_ require compilers to do anything. A completely
valid way of implementing a command line argument like, say,
`--target-private-directory foo` is to drop it to the floor or even
say that there is no compiler flag to specify such a thing. The only
thing we care about is agreeing that such a thing conceptually might
exist and which properties it would have (e.g. it is the build
system's responsibility to give each top level target its unique dir
and pass compiler flags accordingly).
Actual usage is a whole different thing. For example let us suppose
that the private dir is the same where intermediate object files go
(which makes sense, most build systems already have a private dir for
exactly this use case). 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 and that running the
equivalent of `ninja clean` would remove said files (it being the
build system's responsibility). Similarly scanning Sarif file outputs
for the whole project is simple: go through all private dirs in the
build dir and look for files with a specific file name.
And just to be sure: this is just an example. I'm _not_ saying this is
how Sarif data _should_ work, just that this is one way that it
_could_ work.
File locking and the like would _only_ come into play if some compiler
vendor, out of their own free will and choice, would think of some
internal scheme for sharing. In that case we could say "great, that
directory is yours to do whatever you want, go nuts". And if they
don't want to do that then we can also say "great, nothing changes,
but the directory is still there for you to output auxiliary data
should you want to do that either now or later".
Received on 2024-11-25 11:07:25