GNU bug report logs - #34448
--no-build-details means system-name is nil

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34448 in the body.
You can then email your comments to 34448 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: --no-build-details means system-name is nil
Date: Mon, 11 Feb 2019 20:54:32 -0500

Package: emacs
Version: 27.0.50
Severity: minor

Master at revision 2860f6cec5. If I run

emacs -Q --no-build-details

then (system-name) returns nil. I expect this switch to only affect the
values stored in the Emacs binary, not the run-time result.

I'm also not sure why --no-build-details is a run-time option (as
opposed to a build-time one).

Anyway, this breaks file-locking (cf bug#34355) and makes it impossible
to save a file.

Message #8 received at 34448 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 34448 <at> debbugs.gnu.org
Subject: Re: bug#34448: --no-build-details means system-name is nil
Date: Thu, 10 Oct 2019 00:26:53 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> emacs -Q --no-build-details
>
> then (system-name) returns nil. I expect this switch to only affect the
> values stored in the Emacs binary, not the run-time result.

Yup.  It seems like this was the intention here:

void
init_system_name (void)
{
  if (!build_details)
    {
      /* Set system-name to nil so that the build is deterministic.  */
      Vsystem_name = Qnil;
      return;
    }

which is called from

static void
init_and_cache_system_name (void)
{
  init_system_name ();
  cached_system_name = Vsystem_name;
}

which is called from

DEFUN ("system-name", Fsystem_name, Ssystem_name, 0, 0, 0,
       doc: /* Return the host name of the machine you are running on, as a string.  */)
  (void)
{
  if (EQ (Vsystem_name, cached_system_name))
    init_and_cache_system_name ();
  return Vsystem_name;

Is --no-build-details just meant to be used during builds?  If so, we
can just document that, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 34448 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34448 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#34448: --no-build-details means system-name is nil
Date: Thu, 10 Oct 2019 10:39:03 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 10 Oct 2019 00:26:53 +0200
> Cc: 34448 <at> debbugs.gnu.org
> 
> void
> init_system_name (void)
> {
>   if (!build_details)
>     {
>       /* Set system-name to nil so that the build is deterministic.  */
>       Vsystem_name = Qnil;
>       return;
>     }
> 
> which is called from
> 
> static void
> init_and_cache_system_name (void)
> {
>   init_system_name ();
>   cached_system_name = Vsystem_name;
> }
> 
> which is called from
> 
> DEFUN ("system-name", Fsystem_name, Ssystem_name, 0, 0, 0,
>        doc: /* Return the host name of the machine you are running on, as a string.  */)
>   (void)
> {
>   if (EQ (Vsystem_name, cached_system_name))
>     init_and_cache_system_name ();
>   return Vsystem_name;
> 
> Is --no-build-details just meant to be used during builds?  If so, we
> can just document that, I guess?

Yes, documenting that would be a good compromise, I think.

Message #14 received at 34448 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34448 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#34448: --no-build-details means system-name is nil
Date: Fri, 11 Oct 2019 09:05:51 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Is --no-build-details just meant to be used during builds?  If so, we
>> can just document that, I guess?
>
> Yes, documenting that would be a good compromise, I think.

I've now done this, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.