GNU bug report logs - #58224
29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"

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 58224 in the body.
You can then email your comments to 58224 AT debbugs.gnu.org in the normal way.

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than
 byte-compiled file"
Date: Sat, 1 Oct 2022 16:15:09 +0200

Severity: wishlist

Every time I "make bootstrap", I get a ton of spurious messages (see
below).  I believe they started showing up with Lars' much appreciated
work on improving build speeds.  I have tripped myself up over this
more than once, and I suspect it will confuse users too.

Is there any chance we could do something to silence them?  If we
can't solve it "properly", how about just a hack?  For example, could
we add some variable to suppress these messages at this stage of the
build process?

For completeness, I almost always build --with-native-compilation, in
case that matters.

  ELC+ELN  emacs-lisp/cconv.elc
  ELC+ELN  emacs-lisp/byte-opt.elc
  ELC+ELN  emacs-lisp/bytecomp.elc
  ELC+ELN  emacs-lisp/comp.elc
  ELC+ELN  emacs-lisp/comp-cstr.elc
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/cconv.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/cconv.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/cconv.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/cconv.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/cconv.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/comint.el’ newer than
byte-compiled file; using older file
  ELC+ELN  emacs-lisp/loaddefs-gen.elc
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/bytecomp.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/icons.el’ newer
than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/comp-cstr.el’
newer than byte-compiled file; using older file
Source file ‘/Users/skangas/wip/emacs/lisp/emacs-lisp/byte-opt.el’
newer than byte-compiled file; using older file

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sat, 01 Oct 2022 16:29:37 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Every time I "make bootstrap", I get a ton of spurious messages (see
> below).  I believe they started showing up with Lars' much appreciated
> work on improving build speeds. 

No, I think they were there before that.

> Is there any chance we could do something to silence them?  If we
> can't solve it "properly", how about just a hack?  For example, could
> we add some variable to suppress these messages at this stage of the
> build process?

Yes, making the warnings go away would be nice.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50;
 "make bootstrap" spuriously warns: "comp.el newer than byte-compiled
 file"
Date: Sat, 01 Oct 2022 17:50:35 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 1 Oct 2022 16:15:09 +0200
> 
> Every time I "make bootstrap", I get a ton of spurious messages (see
> below).  I believe they started showing up with Lars' much appreciated
> work on improving build speeds.  I have tripped myself up over this
> more than once, and I suspect it will confuse users too.

It's not spurious, it's because we deliberately fiddle with the time
stamps to make sure *.elc files are used instead of *.el, to make the
build faster.

(This has nothing to do with what Lars did, it's due to changes by
Alan to speedup the first stage of the bootstrap.)

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alan Mackenzie <acm <at> muc.de>, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sat, 1 Oct 2022 18:10:19 +0200

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

> (This has nothing to do with what Lars did, it's due to changes by
> Alan to speedup the first stage of the bootstrap.)

Oh, right.  I forgot about that.

I'm copying in Alan, in case he has any comments.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sat, 1 Oct 2022 18:11:38 +0000

Hello, Stefan.

On Sat, Oct 01, 2022 at 18:10:19 +0200, Stefan Kangas wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:

> > (This has nothing to do with what Lars did, it's due to changes by
> > Alan to speedup the first stage of the bootstrap.)

> Oh, right.  I forgot about that.

> I'm copying in Alan, in case he has any comments.

Well, my thoughts back when implementing that speedup were that the
speedup was more important than a few irritating messages.  I suppose
that's becomng less true as the long delays from the past fade from
memory.

The particular message about "<file> newer than byte-compile file; using
older file" is hard-coded into Fload in src/lread.c.  It was considered
important enough to supersede the flag variable force-load-messages.  It
also supersedes the parameter NOMESSAGE to Fload.

I don't know why this message is considered so important.  Maybe we
might reconsider its importance.  But there are already two flag
variables meant to control messages from Fload, so adding a third
special one probably wouldn't be a good idea.

This doesn't seem like an easy issue to resolve without nasty special
case code.  Either that, or we reconsider the mechanism of making the
..elc files older to trigger make's recompiling of the .el files to .eln.
Maybe there's a better way of doing that.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sat, 1 Oct 2022 21:15:46 +0000

Hello again, Stefan.

I've hacked a quick fix together.  The idea is to give the variable
force-load-messages an extra possibility, 'never.  This suppresses the
messages we want to suppress.

No guarantees, but the patch is below, if you want to try it out.

On Sat, Oct 01, 2022 at 18:11:38 +0000, Alan Mackenzie wrote:
> Hello, Stefan.

> On Sat, Oct 01, 2022 at 18:10:19 +0200, Stefan Kangas wrote:
> > Eli Zaretskii <eliz <at> gnu.org> writes:

> > > (This has nothing to do with what Lars did, it's due to changes by
> > > Alan to speedup the first stage of the bootstrap.)

> > Oh, right.  I forgot about that.

> > I'm copying in Alan, in case he has any comments.

> Well, my thoughts back when implementing that speedup were that the
> speedup was more important than a few irritating messages.  I suppose
> that's becomng less true as the long delays from the past fade from
> memory.

> The particular message about "<file> newer than byte-compile file; using
> older file" is hard-coded into Fload in src/lread.c.  It was considered
> important enough to supersede the flag variable force-load-messages.  It
> also supersedes the parameter NOMESSAGE to Fload.

> I don't know why this message is considered so important.  Maybe we
> might reconsider its importance.  But there are already two flag
> variables meant to control messages from Fload, so adding a third
> special one probably wouldn't be a good idea.

> This doesn't seem like an easy issue to resolve without nasty special
> case code.  Either that, or we reconsider the mechanism of making the
> ..elc files older to trigger make's recompiling of the .el files to .eln.
> Maybe there's a better way of doing that.



diff --git a/lisp/Makefile.in b/lisp/Makefile.in
index bcf4a3146d..8065487f59 100644
--- a/lisp/Makefile.in
+++ b/lisp/Makefile.in
@@ -70,7 +70,8 @@ BYTE_COMPILE_FLAGS =
   --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
 	$(BYTE_COMPILE_EXTRA_FLAGS)
 # ... but we must prefer .elc files for those in the early bootstrap.
-compile-first: BYTE_COMPILE_FLAGS = $(BYTE_COMPILE_EXTRA_FLAGS)
+compile-first: BYTE_COMPILE_FLAGS = \
+  --eval "(setq force-load-messages 'never)" $(BYTE_COMPILE_EXTRA_FLAGS)
 
 # Files to compile before others during a bootstrap.  This is done to
 # speed up the bootstrap process.  They're ordered by size, so we use
diff --git a/src/lread.c b/src/lread.c
index 51cbf811ba..1ae0f9c0cc 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -1451,7 +1451,9 @@ Return t if the file exists and loads successfully.  */)
                   newer = 1;
 
                   /* If we won't print another message, mention this anyway.  */
-                  if (!NILP (nomessage) && !force_load_messages)
+                  if (!NILP (nomessage) &&
+		      (NILP (Vforce_load_messages)
+		       || !EQ (Vforce_load_messages, Qnever)))
                     {
                       Lisp_Object msg_file;
                       msg_file = Fsubstring (found, make_fixnum (0), make_fixnum (-1));
@@ -1476,7 +1478,9 @@ Return t if the file exists and loads successfully.  */)
 	    }
 	  val = call4 (Vload_source_file_function, found, hist_file_name,
 		       NILP (noerror) ? Qnil : Qt,
-		       (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
+		       (NILP (nomessage) ||
+			(!NILP (Vforce_load_messages) && !EQ (Vforce_load_messages, Qnever)))
+		       ? Qnil : Qt);
 	  return unbind_to (count, val);
 	}
     }
@@ -1529,7 +1533,8 @@ Return t if the file exists and loads successfully.  */)
   if (! NILP (Vpurify_flag))
     Vpreloaded_file_list = Fcons (Fpurecopy (file), Vpreloaded_file_list);
 
-  if (NILP (nomessage) || force_load_messages)
+  if (NILP (nomessage)
+      || (!NILP (Vforce_load_messages) && !EQ (Vforce_load_messages, Qnever)))
     {
       if (is_module)
         message_with_string ("Loading %s (module)...", file, 1);
@@ -1602,7 +1607,9 @@ Return t if the file exists and loads successfully.  */)
       saved_strings[i].size = 0;
     }
 
-  if (!noninteractive && (NILP (nomessage) || force_load_messages))
+  if (!noninteractive && (NILP (nomessage)
+			  || (!NILP (Vforce_load_messages)
+			      && !EQ (Vforce_load_messages, Qnever))))
     {
       if (is_module)
         message_with_string ("Loading %s (module)...done", file, 1);
@@ -5601,10 +5608,13 @@ incompatible byte codes can make Emacs crash when it tries to execute
 them.  */);
   load_dangerous_libraries = 0;
 
-  DEFVAR_BOOL ("force-load-messages", force_load_messages,
-	       doc: /* Non-nil means force printing messages when loading Lisp files.
+  DEFVAR_LISP ("force-load-messages", Vforce_load_messages,
+	       doc: /* t means force printing messages when loading Lisp files.
+`never' means suppress all messages when loading Lisp files.  nil means just print
+certain "important" messages.
+
 This overrides the value of the NOMESSAGE argument to `load'.  */);
-  force_load_messages = 0;
+  Vforce_load_messages = Qnil;
 
   DEFVAR_LISP ("bytecomp-version-regexp", Vbytecomp_version_regexp,
 	       doc: /* Regular expression matching safe to load compiled Lisp files.
@@ -5685,6 +5695,8 @@ that are loaded before your customizations are read!  */);
   DEFSYM (Qdir_ok, "dir-ok");
   DEFSYM (Qdo_after_load_evaluation, "do-after-load-evaluation");
 
+  DEFSYM (Qnever, "never");
+
   staticpro (&read_objects_map);
   read_objects_map = Qnil;
   staticpro (&read_objects_completed);


-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 02 Oct 2022 08:59:16 +0300

> Date: Sat, 1 Oct 2022 21:15:46 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> I've hacked a quick fix together.  The idea is to give the variable
> force-load-messages an extra possibility, 'never.  This suppresses the
> messages we want to suppress.

Instead of inventing a new value that overrides the non-nil value, why
not simply reset the variable to nil?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 10:43:44 +0000

Hello, Eli.

On Sun, Oct 02, 2022 at 08:59:16 +0300, Eli Zaretskii wrote:
> > Date: Sat, 1 Oct 2022 21:15:46 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > I've hacked a quick fix together.  The idea is to give the variable
> > force-load-messages an extra possibility, 'never.  This suppresses the
> > messages we want to suppress.

> Instead of inventing a new value that overrides the non-nil value, why
> not simply reset the variable to nil?

force-load-messages is nil by default, and currently isn't used at all
by Emacs.  It seems to be a pure debugging variable.

The NOMESSAGE argument to Fload when non-nil, causes the unwanted
message:

    Source file `foo.el' newer than byte-compiled file; using older file

..  When NOMESSAGE is nil, we get instead

    Loading foo.elc (compiled; note, source file is newer)...

..  Whichever setting of NOMESSAGE and force-load-messages we use, we get
one of the above messages displayed.  So, I'm proposing using a new
value 'never for force-load-messages to mean display neither of these
messages.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: acm <at> muc.de, stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 02 Oct 2022 14:04:08 +0300

> Date: Sun, 2 Oct 2022 10:43:44 +0000
> Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > Instead of inventing a new value that overrides the non-nil value, why
> > not simply reset the variable to nil?
> 
> force-load-messages is nil by default, and currently isn't used at all
> by Emacs.  It seems to be a pure debugging variable.
> 
> The NOMESSAGE argument to Fload when non-nil, causes the unwanted
> message:
> 
>     Source file `foo.el' newer than byte-compiled file; using older file
> 
> ..  When NOMESSAGE is nil, we get instead
> 
>     Loading foo.elc (compiled; note, source file is newer)...
> 
> ..  Whichever setting of NOMESSAGE and force-load-messages we use, we get
> one of the above messages displayed.  So, I'm proposing using a new
> value 'never for force-load-messages to mean display neither of these
> messages.

I don't want to complicate the public Lisp API because we have a
singular situation at some point of the bootstrap, and for minor
aesthetic reasons at that; that is the tail wagging the dog.  So let's
fix this more subtly.

How about recognizing (inside Fload) a specific time stamp of the
older file we use (we set it to the beginning of the Epoch, right?),
and suppressing the message in that case?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 11:32:29 +0000

Hello, Eli.

On Sun, Oct 02, 2022 at 14:04:08 +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 10:43:44 +0000
> > Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > Instead of inventing a new value that overrides the non-nil value, why
> > > not simply reset the variable to nil?

> > force-load-messages is nil by default, and currently isn't used at all
> > by Emacs.  It seems to be a pure debugging variable.

> > The NOMESSAGE argument to Fload when non-nil, causes the unwanted
> > message:

> >     Source file `foo.el' newer than byte-compiled file; using older file

> > ..  When NOMESSAGE is nil, we get instead

> >     Loading foo.elc (compiled; note, source file is newer)...

> > ..  Whichever setting of NOMESSAGE and force-load-messages we use, we get
> > one of the above messages displayed.  So, I'm proposing using a new
> > value 'never for force-load-messages to mean display neither of these
> > messages.

> I don't want to complicate the public Lisp API because we have a
> singular situation at some point of the bootstrap, and for minor
> aesthetic reasons at that; that is the tail wagging the dog.  So let's
> fix this more subtly.

I agree.

> How about recognizing (inside Fload) a specific time stamp of the
> older file we use (we set it to the beginning of the Epoch, right?),
> and suppressing the message in that case?

:-)  That's a nice idea.  I'll see if I can get that done today.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 15:38:25 +0000

Hello, Eli.

On Sun, Oct 02, 2022 at 14:04:08 +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 10:43:44 +0000
> > Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > Instead of inventing a new value that overrides the non-nil value, why
> > > not simply reset the variable to nil?

> > force-load-messages is nil by default, and currently isn't used at all
> > by Emacs.  It seems to be a pure debugging variable.

> > The NOMESSAGE argument to Fload when non-nil, causes the unwanted
> > message:

> >     Source file `foo.el' newer than byte-compiled file; using older file

> > ..  When NOMESSAGE is nil, we get instead

> >     Loading foo.elc (compiled; note, source file is newer)...

> > ..  Whichever setting of NOMESSAGE and force-load-messages we use, we get
> > one of the above messages displayed.  So, I'm proposing using a new
> > value 'never for force-load-messages to mean display neither of these
> > messages.

> I don't want to complicate the public Lisp API because we have a
> singular situation at some point of the bootstrap, and for minor
> aesthetic reasons at that; that is the tail wagging the dog.  So let's
> fix this more subtly.

> How about recognizing (inside Fload) a specific time stamp of the
> older file we use (we set it to the beginning of the Epoch, right?),
> and suppressing the message in that case?

I've got this working, but ....

In lread.c I've got:

  struct timespec epoch_timespec = {(time_t)0, 0}; /* 1970-01-01T00:00 UTC */ 

, which clearly isn't satisfactory.  Can you (or anybody else) give me a
clue as how to convert a human readable time into a struct timespec?
I've spent most of the afternoon searching and grepping lots of .h files,
and haven't come up with anything, yet.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 02 Oct 2022 18:54:10 +0300

> Date: Sun, 2 Oct 2022 15:38:25 +0000
> Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> In lread.c I've got:
> 
>   struct timespec epoch_timespec = {(time_t)0, 0}; /* 1970-01-01T00:00 UTC */ 
> 
> , which clearly isn't satisfactory.

I'm not sure I follow: why not satisfactory?

> Can you (or anybody else) give me a clue as how to convert a human
> readable time into a struct timespec?  I've spent most of the
> afternoon searching and grepping lots of .h files, and haven't come
> up with anything, yet.

Is mktime the function you are after?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 16:46:01 +0000

Hello, Eli.

On Sun, Oct 02, 2022 at 18:54:10 +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 15:38:25 +0000
> > Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > In lread.c I've got:

> >   struct timespec epoch_timespec = {(time_t)0, 0}; /* 1970-01-01T00:00 UTC */ 

> > , which clearly isn't satisfactory.

> I'm not sure I follow: why not satisfactory?

Don't we build for operating systems with different epochs?

> > Can you (or anybody else) give me a clue as how to convert a human
> > readable time into a struct timespec?  I've spent most of the
> > afternoon searching and grepping lots of .h files, and haven't come
> > up with anything, yet.

> Is mktime the function you are after?

Yes thanks!  But it's horribly complicated, involving wierd readings and
settings of the TZ environment variable, and so on.  If a binary zero
time would do (as above), maybe it would be satisfactory.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: acm <at> muc.de, stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 02 Oct 2022 20:07:26 +0300

> Date: Sun, 2 Oct 2022 16:46:01 +0000
> Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > In lread.c I've got:
> 
> > >   struct timespec epoch_timespec = {(time_t)0, 0}; /* 1970-01-01T00:00 UTC */ 
> 
> > > , which clearly isn't satisfactory.
> 
> > I'm not sure I follow: why not satisfactory?
> 
> Don't we build for operating systems with different epochs?

No, the Epoch is the same for everyone.  It's a Posix notion, AFAIK.

> > Is mktime the function you are after?
> 
> Yes thanks!  But it's horribly complicated, involving wierd readings and
> settings of the TZ environment variable, and so on.

Not if you are interested in UTC.

> If a binary zero time would do (as above), maybe it would be
> satisfactory.  ;-)

Yes.

Message #49 received at 58224-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Cc: acm <at> muc.de, 58224-done <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 20:37:14 +0000

Hello, Eli and Stefan.

On Sun, Oct 02, 2022 at 20:07:26 +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 16:46:01 +0000
> > Cc: stefankangas <at> gmail.com, 58224 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > > In lread.c I've got:

> > > >   struct timespec epoch_timespec = {(time_t)0, 0}; /* 1970-01-01T00:00 UTC */ 

> > > > , which clearly isn't satisfactory.

> > > I'm not sure I follow: why not satisfactory?

> > Don't we build for operating systems with different epochs?

> No, the Epoch is the same for everyone.  It's a Posix notion, AFAIK.

> > > Is mktime the function you are after?

> > Yes thanks!  But it's horribly complicated, involving wierd readings and
> > settings of the TZ environment variable, and so on.

> Not if you are interested in UTC.

> > If a binary zero time would do (as above), maybe it would be
> > satisfactory.  ;-)

> Yes.

OK, that's great!  I've committed a patch, and I'm closing the bug with
this post.

-- 
Alan Mackenzie (Nuremberg, Germanay).

Message #52 received at 58224-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 58224-done <at> debbugs.gnu.org
Subject: Re: bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el
 newer than byte-compiled file"
Date: Sun, 2 Oct 2022 23:29:36 +0200

Alan Mackenzie <acm <at> muc.de> writes:

> I've committed a patch, and I'm closing the bug with this post.

Thanks!  It works great.

Previous Next

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