Re: [PATCH PING] Honor 'SOURCE_DATE_EPOCH' when generating autoloads.

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
> We could come up with something even less probable.

We could, yes. It should not be a valid domain name, for example. But whatever 
magic cookie we came up with, we would need to document it so that user code can 
avoid displaying it. And to avoid typos it would be better to make it a named 
constant. And we would need to do something similar, with different named 
constants, for similar issues such as emacs-build-time. And we would never 
eliminate the possibility that someone (if only to be contrary, e.g., because 
they are attacking Emacs) would use the magic-cookie as a host name. All in all, 
it would be a relatively complicated solution to what should be a simple problem.

>> >In this sense, the Dec. 25 change that introduced the system build name into the
>> >output of report-emacs-bug was a misstep.
> No, it isn't.  I needed this information many times when examining bug
> reports, and I'm not going to give it up.

My comment’s “in the sense” referred to the sense of its previous paragraph (not 
quoted above) which talked about deterministic builds; it did not refer to 
building Emacs in general. In some cases it can be useful to have the build 
hostname embedded in the executable even at the cost of deterministic builds. 
However, many people (including myself) prefer deterministic builds, and for 
them embedding the build hostname is counterproductive, and that is why it is 
useful to have an option to suppress it.

> Can I have some minimal
> respect from fellow developers, and some minimal credit that I do
> things for a reason?

Nothing in my commentary was intended to exhibit any disrespect. It was intended 
to be purely technical commentary. If it seemed otherwise, I apologize.

>>> > >It sounds strange to send users to documentation for such a simple issue.
>> >
>> >No matter what we do here, we will need documentation that users can refer to on
>> >occasion. Even simple approaches like nil-if-unknown require some documentation.
>> >More-complicated approaches like magic-cookie-if-unknown would require more of it.
> You are ducking the issue.

I do not see what I am ducking here. Surely you are not advocating leaving the 
behavior undocumented. Are you objecting to the convention of using nil to 
represent lack of information? If so, how about if we use some other symbol, 
such as ‘unknown’? Although that would be a bit more of a pain to document and 
use, it would also be OK and for the reasons discussed above would be better 
than a magic-cookie string.