Date: Tue, 29 Oct 2024 16:40:49 +0000
[Boris]
> I am merely pointing out that, at least from the build system POV,
> the requirements discussed here (i.e., additional inputs/outputs
> during compilation) is nothing fundamentally new.
Thanks for clarifying.
> 1. If the compiler is not able to communicate these additional
> inputs/output to the build system, then it's up to the user
> to hack around the fallout (which is what those compiler
> options to override __DATE__/__TIME__ are for).
If the user is aware that that is the source of their build system not rebuilding. The code may be authored by the user, or authored by third party providing a library "framework" header which is totally unknown or out of their control.
> 2. If the compiler is able to communicate these additional
> inputs/outputs to the build system, then modern build systems
> should be able to handle it (including dynamic inputs/outputs)
For that work, the feature has to be specified in such a way that it is reportable by the compiler.
> and legacy build systems will hold up the progress, just like
> they do with modules.
For modules, the compiler is able to report dependencies. Do we have analogous situation here?
> So nothing new.
That is the conjecture; we are still working on establishing it as a truth :-)
-- Gaby
-----Original Message-----
From: Boris Kolpackov <boris_at_[hidden]>
Sent: Tuesday, October 29, 2024 6:39 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Gabriel Dos Reis via SG15 <sg15_at_[hidden]>
Subject: Re: [isocpp-sg15] [P2758] Emitting messages at compile time
Gabriel Dos Reis <gdr_at_[hidden]> writes:
> [Boris]
> > Sure, though I don't think this is a novel problem: you can already
> > easily achieve such non-determinism with the __DATE__/__TIME__ macros.
>
> Sorry, I don't follow.
>
> The __DATE__ and __TIME__ non-determinism issue is solved not by the
> build systems directly, but by compilers offering options. Are you
> equating the non-determinism of __DATE__/__FILE__ with that of what
> we are discussing here? If so, how does that work?
I am merely pointing out that, at least from the build system POV,
the requirements discussed here (i.e., additional inputs/outputs
during compilation) is nothing fundamentally new. Specifically:
1. If the compiler is not able to communicate these additional
inputs/output to the build system, then it's up to the user
to hack around the fallout (which is what those compiler
options to override __DATE__/__TIME__ are for).
2. If the compiler is able to communicate these additional
inputs/outputs to the build system, then modern build systems
should be able to handle it (including dynamic inputs/outputs)
and legacy build systems will hold up the progress, just like
they do with modules. So nothing new.
> I am merely pointing out that, at least from the build system POV,
> the requirements discussed here (i.e., additional inputs/outputs
> during compilation) is nothing fundamentally new.
Thanks for clarifying.
> 1. If the compiler is not able to communicate these additional
> inputs/output to the build system, then it's up to the user
> to hack around the fallout (which is what those compiler
> options to override __DATE__/__TIME__ are for).
If the user is aware that that is the source of their build system not rebuilding. The code may be authored by the user, or authored by third party providing a library "framework" header which is totally unknown or out of their control.
> 2. If the compiler is able to communicate these additional
> inputs/outputs to the build system, then modern build systems
> should be able to handle it (including dynamic inputs/outputs)
For that work, the feature has to be specified in such a way that it is reportable by the compiler.
> and legacy build systems will hold up the progress, just like
> they do with modules.
For modules, the compiler is able to report dependencies. Do we have analogous situation here?
> So nothing new.
That is the conjecture; we are still working on establishing it as a truth :-)
-- Gaby
-----Original Message-----
From: Boris Kolpackov <boris_at_[hidden]>
Sent: Tuesday, October 29, 2024 6:39 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Gabriel Dos Reis via SG15 <sg15_at_[hidden]>
Subject: Re: [isocpp-sg15] [P2758] Emitting messages at compile time
Gabriel Dos Reis <gdr_at_[hidden]> writes:
> [Boris]
> > Sure, though I don't think this is a novel problem: you can already
> > easily achieve such non-determinism with the __DATE__/__TIME__ macros.
>
> Sorry, I don't follow.
>
> The __DATE__ and __TIME__ non-determinism issue is solved not by the
> build systems directly, but by compilers offering options. Are you
> equating the non-determinism of __DATE__/__FILE__ with that of what
> we are discussing here? If so, how does that work?
I am merely pointing out that, at least from the build system POV,
the requirements discussed here (i.e., additional inputs/outputs
during compilation) is nothing fundamentally new. Specifically:
1. If the compiler is not able to communicate these additional
inputs/output to the build system, then it's up to the user
to hack around the fallout (which is what those compiler
options to override __DATE__/__TIME__ are for).
2. If the compiler is able to communicate these additional
inputs/outputs to the build system, then modern build systems
should be able to handle it (including dynamic inputs/outputs)
and legacy build systems will hold up the progress, just like
they do with modules. So nothing new.
Received on 2024-10-29 16:40:52