On 3/10/25 8:24 PM, Thiago Macieira via Std-Proposals wrote:
> On Monday, 10 March 2025 15:59:20 Pacific Daylight Time Tom Honermann via Std-
> Proposals wrote:
>>> When you build it again it is technically a new build time, right?
>> How is that different from the status quo given the existence of
>> __TIME__, __DATE__, and __FILE__ (for relocatable builds)?
> (reproducible)

I meant relocatable or, more accurately, location independent. A build
might be reproducible only if its source files retain their relative
positions in the VFS. A build system that supports relocatable builds
might also provide location independent reproducible builds (in
conjunction with -fmacro-prefix-map or similar).

>
> It isn't. That's why I'm arguing that, if we are to have this feature —which I
> oppose— then it should be implemented using a preprocessor token so the
> behaviour is exactly the same as that of __TIME__:
>
> If any of the source files or headers that your build tool tracks has changed,
> it will start a new compilation. This will cause the preprocessed output to be
> different, which means the cache lookup will be a miss, and leading the cache
> tool to execute the actual compiler, thus giving you a new object file and a
> new binary.
>
> I do note you can already do this with command-line options:
> -DUNIXTIME=$(date +%s)
>
> But this is harder to find and fix for reproducibility than a compiler feature.
> So if there is sufficient interest in this feature, I would prefer it be in the
> compiler.

I agree that, should sufficient motivation arise to add the proposed
support, that features should be provided to support reproducible builds.

I personally don't see sufficient motivation for this proposal yet; I
would still like to see more examples of anticipated idiomatic usage.

My goal in this discussion is to prevent prematurely killing a
potentially useful feature too quickly due to concerns about misuse or
problems that might not happen in practice or that can be mitigated.

As a reminder to everyone, quoting from
https://isocpp.org/std/submit-a-proposal, the goal of this mailing list
is to best prepare a proposal author and their written proposal for
further review. In other words, the intent is to provide constructive
feedback.

    Committee members and other interested experts will be able to give
    you feedback to let you gauge the level of interest in that kind of
    feature in general, and also feedback on your specific proposal’s
    approach to it in particular to help you refine it in the next step.

Stating opposition to a proposal can potentially be useful information
to the author. However, it is generally more useful to list changes that
would get you from an opposing stance to a supporting one (something
Thiago tends to do well, as demonstrated above). I caution proposal
authors not to be too dissuaded by negative reactions expressed on this
mailing list; not everyone here actively participates in WG21 meetings
where voting actually happens.

Tom.