[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: Mon, 28 Dec 2015 10:00:22 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Eli Zaretskii wrote:

Please let's nott remove this part, we are not removing the variable
(and won't be any time soon).  Let's just document that the value can
be nil in a "deterministic build".

OK, I will add the usual text saying that the variable can be nil if the information is not available.

-;; I think this should be obsoleted/removed.  It's just one more meaningless
-;; difference between different builds.  It's usually not even an fqdn.
-(defconst emacs-build-system (system-name)
-  "Name of the system on which Emacs was built.")
+(defconst emacs-build-system
+  (if (not deterministic-build) (system-name))
+  "Name of the system on which Emacs was built, or nil if not available.")

This causes an error in "M-x report-emacs-bug", so something should be
done here or there.

What sort of error? It seems to work for me (not that I actually went all the way and sent the email).

I had to back out the recent IDNA changes, as they broke report-emacs-bug -- perhaps that is what you noticed?

(I don't understand why you are so objected to
keeping this a string

Consistency and simplicity. Consistency, because we should treat emacs-build-system consistently with other primitives like process-attributes and memory-info that return nil when the information is not available. Simplicity, because it's simpler for code to test for nil than for some reserved string like "unknown"; you can see examples of this in the most recent patch I proposed. Besides, we shouldn't prevent Emacs from working correctly on a machine whose host name really is "unknown".

reply via email to

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