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

[Paul Eggert]

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".