Date: Mon, 28 Oct 2024 07:06:36 -0400
To disagree with Boris on determinism as a concern in build systems, there
are tricks to replace __DATE__ and __TIME__ with deterministic values,
especially because they are well known and simple. We should be cautious
about adding non-deterministic APIs to the C++ compile time, especially
complicated information such as opening and reading an arbitrary file
handle.
To understand a specific concern, note that the ninja build system
especially expects to be able to model all of the possible input files in
ninja files. If that is not generally possible until doing nontrivial C++
execution at compile time, then certain valid C++ idioms will be
incompatible with a popular C++ ecosystem tool.
That being said, I think as long as we can still accomplish affordable
pre-compile dependency scanning (i.e., accurate clang-scan-deps, g++ -M,
etc.) early enough for build systems to have an accurate dependency graph,
we can rule out compile time messages as a determinism concern. But we
should keep an eye out for accidentally introducing new build determinism
problems.
Bret
On Mon, Oct 28, 2024, 03:50 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Gabriel Dos Reis <gdr_at_[hidden]> writes:
>
> > If the generated code is using some intermediary file that the compiler
> > can surface to the build system, that would work. My concern though is
> > around code generation at compile time that does not use any intermediary
> > file surfaced to the build system. If that process is not deterministic
> > (because of arbitrary side effects) then, I think we have a problem with
> > how build systems work today. Do you agree?
>
> Sure, though I don't think this is a novel problem: you can already
> easily achieve such non-determinism with the __DATE__/__TIME__ macros.
> I don't know of any build system that cares to handle such cases (beyond
> the "don't do this if you want deterministic/reproducible builds" advice
> to the user). And I don't believe this will change.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
are tricks to replace __DATE__ and __TIME__ with deterministic values,
especially because they are well known and simple. We should be cautious
about adding non-deterministic APIs to the C++ compile time, especially
complicated information such as opening and reading an arbitrary file
handle.
To understand a specific concern, note that the ninja build system
especially expects to be able to model all of the possible input files in
ninja files. If that is not generally possible until doing nontrivial C++
execution at compile time, then certain valid C++ idioms will be
incompatible with a popular C++ ecosystem tool.
That being said, I think as long as we can still accomplish affordable
pre-compile dependency scanning (i.e., accurate clang-scan-deps, g++ -M,
etc.) early enough for build systems to have an accurate dependency graph,
we can rule out compile time messages as a determinism concern. But we
should keep an eye out for accidentally introducing new build determinism
problems.
Bret
On Mon, Oct 28, 2024, 03:50 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Gabriel Dos Reis <gdr_at_[hidden]> writes:
>
> > If the generated code is using some intermediary file that the compiler
> > can surface to the build system, that would work. My concern though is
> > around code generation at compile time that does not use any intermediary
> > file surfaced to the build system. If that process is not deterministic
> > (because of arbitrary side effects) then, I think we have a problem with
> > how build systems work today. Do you agree?
>
> Sure, though I don't think this is a novel problem: you can already
> easily achieve such non-determinism with the __DATE__/__TIME__ macros.
> I don't know of any build system that cares to handle such cases (beyond
> the "don't do this if you want deterministic/reproducible builds" advice
> to the user). And I don't believe this will change.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-10-28 11:06:50