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

[Eli Zaretskii <eliz@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

> Cc: p.stephani2@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 28 Dec 2015 10:00:22 -0800
> 
> 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.

Thanks.

> >> -;; 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?

"Wrong type argument: char-or-string-p, nil".  See the attached image,
and note that the cursor stops where it should have displayed the
build system name, and there's nothing in the buffer beyond that
point.

> It seems to work for me (not that I actually went all the way and
> sent the email).

No need to send, just modify version.el to give emacs-build-system the
nil value, rebuild Emacs, and type "M-x report-emacs-bug RET foo RET".

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

No, I don't think so.  It's the 'insert' call in emacsbug.el that
errors out, since it cannot handle a nil argument.

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

That's why I asked it not to be "unknown".  But "elided" is different:
it tells that we deliberately conceal the build system.  I'm okay with
other, better, strings, if they explain the situation better.

My point is that the reproducible build is not (yet) the standard
build, it's more like an anomaly at this time, so I thought we should
have the string explain itself.  And nil cannot explain anything.


[-- Attachment #2: emacs-bug-error.PNG --]
[-- Type: image/png, Size: 35220 bytes --]