Date: Thu, 28 Nov 2024 10:07:17 +0200
Jussi Pakkanen <jpakkane_at_[hidden]> writes:
> A top level target would be a shared/static library, executable or
> module. Exactly as Meson and CMake currently do it. I don't really
> know how object libraries work currently, but the build system could
> generate a dir for those cases too.
What is the point of placing the output to this top-level target
directory rather than the per-TU directory as suggested by Mathias?
My feeling is so that the additional outputs are aggregated on the
per end-product basis so that, for example, one can easily find all
the SARIF files that describe a library build. If that's the case,
then creating a separate directory for utility libraries would break
this aggregation.
> > Also, what happens if the same object file is used as input to build
> > multiple, say, executables? Who is its top-level target?
>
> When it is being compiled the private dir is whatever target it is
> being built for.
I would expect this to be racy in most build systems. It would
definitely be in build2: depending on which executable-object
dependency caused the compilation, the additional outputs would
end up in one executable's top-level directory or another.
If this facility is to be added, I would suggest going with the
semantics proposed by Mathias: output directory per TU.
> A top level target would be a shared/static library, executable or
> module. Exactly as Meson and CMake currently do it. I don't really
> know how object libraries work currently, but the build system could
> generate a dir for those cases too.
What is the point of placing the output to this top-level target
directory rather than the per-TU directory as suggested by Mathias?
My feeling is so that the additional outputs are aggregated on the
per end-product basis so that, for example, one can easily find all
the SARIF files that describe a library build. If that's the case,
then creating a separate directory for utility libraries would break
this aggregation.
> > Also, what happens if the same object file is used as input to build
> > multiple, say, executables? Who is its top-level target?
>
> When it is being compiled the private dir is whatever target it is
> being built for.
I would expect this to be racy in most build systems. It would
definitely be in build2: depending on which executable-object
dependency caused the compilation, the additional outputs would
end up in one executable's top-level directory or another.
If this facility is to be added, I would suggest going with the
semantics proposed by Mathias: output directory per TU.
Received on 2024-11-28 08:06:16