On 10/25/24 6:41 AM, Gabriel Dos Reis via SG15 wrote:
> 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?

In my experience, yes. For example, MSVC implicitly consults the INCLUDE
environment variable. Build systems that don't track changes to that
environment variable between builds will assume no need for a rebuild if
that environment variable is changed.

>
> 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? If not, how
> are we sure of that?

There has to be some change to the compiler input (source files,
environment variables, current working directory, filesystem, etc...)
for its output to be affected. Anything the build system doesn't track
can lead to a failure to rebuild.

TOCTOU issues may arise if the build system doesn't have a complete
build graph that models inputs and outputs.

Tom.

>
> -- Gaby
>
>
>
> ------------------------------------------------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Matthias
> Kretz via SG15 <sg15_at_[hidden]>
> *Sent:* Friday, October 25, 2024 3:12:24 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Matthias Kretz <m.kretz_at_[hidden]>
> *Subject:* Re: [isocpp-sg15] [P2758] Emitting messages at compile time
> On Friday, 25 October 2024 07:55:51 GMT+2 Corentin via SG15 wrote:
> > > So that no good deed goes unpunished 😊 I'll warn you that I
> intend to be
> > > greedy: Some of us will be asking for general compile-time I/O, or at
> > > least
> > > O (output), in a consteval function. For example […]
> >
> > None of the novel reflection features have deployment experience and
> a lot
> > of that hasn't been implemented. […]
> > Maybe we can take it one step at a time?
>
> I agree and disagree. The important point Herb is making is that these
> features are related. Consequently, it is useful to keep the bigger
> picture in
> mind while working on one aspect of compile-time I/O.
>
> Regarding additional output files from compilers: This isn't novel.
> What is
> novel is that the C++ source gets more say in the content of such
> files. I
> believe file paths would typically be set via compiler flags anyway.
> In that
> case it's still on the radar of the build system what's going on.
>
> --
> ──────────────────────────────────────────────────────────────────────────
> Dr. Matthias Kretz
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmattkretz.github.io%2F&data=05%7C02%7Cgdr%40microsoft.com%7C1b423d2d0c5c4d74138508dcf4dd88af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638654479530970594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=gdOQbCF1gnBwulnU8jqfSNTmlX6fBscF%2Fk8PTJdXvVE%3D&reserved=0
> <https://mattkretz.github.io/>
> GSI Helmholtz Center for Heavy Ion Research
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgsi.de%2F&data=05%7C02%7Cgdr%40microsoft.com%7C1b423d2d0c5c4d74138508dcf4dd88af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638654479530995115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tg55B8go3gtRj%2FXqtQv0WENn6n%2BOlReo%2Ba8LrJIQNAA%3D&reserved=0
> <https://gsi.de/>
> std::simd
> ──────────────────────────────────────────────────────────────────────────
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15