[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [PATCH PING] Honor 'SOURCE_DATE_EPOCH' when generating autoloads.
Date: Tue, 29 Dec 2015 12:33:26 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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 
>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 
>occasion. Even simple approaches like nil-if-unknown require some 
>More-complicated approaches like magic-cookie-if-unknown would require more of 
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]