[Boris]
> I would say any build system that doesn't rely on a magic crystal ball
> has no choice but to make such an assumption.

Thanks, that is what I thought and I wanted to verify that we are all working from the same accepted facts.

> FWIW, some build systems (e.g., build2) support not only dynamic
> dependencies but also dynamic target groups. That is, discovering
> during the build the exact set of files that would be produced by
> a given tool given the inputs. I think this mechanism can be used
> to handle compiling C++ TUs that produce additional output files,
> even if the exact set depends on the TU contents and/or other inputs.
> C++ compilers will need to support communicating this information
> to the build system, similar to, or even using the same mechanism
> as, how they currently communicate the dependencies (e.g., headers).

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?

-- Gaby

-----Original Message-----
From: Boris Kolpackov <boris_at_[hidden]>
Sent: Friday, October 25, 2024 5:49 AM
To: Gabriel Dos Reis via SG15 <sg15_at_[hidden]>
Cc: Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [isocpp-sg15] [P2758] Emitting messages at compile time

Gabriel Dos Reis via SG15 <sg15_at_[hidden]> writes:

> Is it true that conventional build systems make the assumption that
> if the contents of a source file doesn't change, and other compiler
> flags and dependencies stay the same, then there is no need for rebuild?

I would say any build system that doesn't rely on a magic crystal ball
has no choice but to make such an assumption.


> If that assumption is true, is there a concern that it will get
> invalidated when arbitrary side effects are allowed to change the
> conceptual contents (as generated by static code generation) of a
> given source file? If yes, what is the new build model?

FWIW, some build systems (e.g., build2) support not only dynamic
dependencies but also dynamic target groups. That is, discovering
during the build the exact set of files that would be produced by
a given tool given the inputs. I think this mechanism can be used
to handle compiling C++ TUs that produce additional output files,
even if the exact set depends on the TU contents and/or other inputs.
C++ compilers will need to support communicating this information
to the build system, similar to, or even using the same mechanism
as, how they currently communicate the dependencies (e.g., headers).