Date: Fri, 07 Mar 2025 18:31:00 +0000
On Thursday, March 6th, 2025 at 17:10, Jonathan Wakely <cxx_at_[hidden]> wrote:
> > Even if this functionality were added, it would not affect reproducible builds in _any_ way, _unless the developers of the software chose to use it_! Given that it is largely incompatible with reproducible/deterministic builds, why would they?
>
>
> The people writing the code might not be the ones compiling it. Linux distros want reproducible builds, and it's a problem if that's impossible because some software they want to package insists on using clocks and there's no way to override the time (the way there is for __TIME__).
Fair point, and to be clear, I have no objection to (a) extending -Wdate-time and equivalent options to produce a warning if the functionality is used; (b) offering a standardized way to override the system clock and supply the time explicitly; and (c) even offering a standardized way to disable the functionality entirely, so the code produces an error..
> I assure you that reproducible builds are important.
Thank you, but I don't think I ever argued that they were not important. Over the past 25 years I had to implement determinstic builds more than once (sometimes for regulatory reasons, others because it made sense given the project's goals) and at least once I had to go to great lengths to get them to work. So I am very aware of both how important they are and what a pain point they can be to get right. I assure you that I am not out here looking to twist the standard so as to make them harder in any way.
At the same time, I don't think that we should use reproducible builds as an excuse to not have this functionality anymore than I think we should disallow bakeries from baking fresh bread because I am doing keto and the aroma of fresh-baked goods is PAINFUL.
Anyways, as I said in a different post, a number of legitimate concerns, apart from determinism, have been raised, some of which I had not considered. I'll give some more thought to the proposal and try to address as many of the issues as I can going forward.
Best regards,
Nik Bougalis
> > Even if this functionality were added, it would not affect reproducible builds in _any_ way, _unless the developers of the software chose to use it_! Given that it is largely incompatible with reproducible/deterministic builds, why would they?
>
>
> The people writing the code might not be the ones compiling it. Linux distros want reproducible builds, and it's a problem if that's impossible because some software they want to package insists on using clocks and there's no way to override the time (the way there is for __TIME__).
Fair point, and to be clear, I have no objection to (a) extending -Wdate-time and equivalent options to produce a warning if the functionality is used; (b) offering a standardized way to override the system clock and supply the time explicitly; and (c) even offering a standardized way to disable the functionality entirely, so the code produces an error..
> I assure you that reproducible builds are important.
Thank you, but I don't think I ever argued that they were not important. Over the past 25 years I had to implement determinstic builds more than once (sometimes for regulatory reasons, others because it made sense given the project's goals) and at least once I had to go to great lengths to get them to work. So I am very aware of both how important they are and what a pain point they can be to get right. I assure you that I am not out here looking to twist the standard so as to make them harder in any way.
At the same time, I don't think that we should use reproducible builds as an excuse to not have this functionality anymore than I think we should disallow bakeries from baking fresh bread because I am doing keto and the aroma of fresh-baked goods is PAINFUL.
Anyways, as I said in a different post, a number of legitimate concerns, apart from determinism, have been raised, some of which I had not considered. I'll give some more thought to the proposal and try to address as many of the issues as I can going forward.
Best regards,
Nik Bougalis
Received on 2025-03-07 18:31:12