* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
@ 2022-10-01 14:15 Stefan Kangas
2022-10-01 14:29 ` Lars Ingebrigtsen
2022-10-01 14:50 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Stefan Kangas @ 2022-10-01 14:15 UTC (permalink / raw)
To: 58224
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 14:15 bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file" Stefan Kangas
@ 2022-10-01 14:29 ` Lars Ingebrigtsen
2022-10-01 14:50 ` Eli Zaretskii
1 sibling, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 14:29 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58224
Stefan Kangas <stefankangas@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 14:15 bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file" Stefan Kangas
2022-10-01 14:29 ` Lars Ingebrigtsen
@ 2022-10-01 14:50 ` Eli Zaretskii
2022-10-01 16:10 ` Stefan Kangas
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-10-01 14:50 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58224
> From: Stefan Kangas <stefankangas@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.)
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 14:50 ` Eli Zaretskii
@ 2022-10-01 16:10 ` Stefan Kangas
2022-10-01 18:11 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-10-01 16:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alan Mackenzie, 58224
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 16:10 ` Stefan Kangas
@ 2022-10-01 18:11 ` Alan Mackenzie
2022-10-01 21:15 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-01 18:11 UTC (permalink / raw)
To: Stefan Kangas; +Cc: acm, Eli Zaretskii, 58224
Hello, Stefan.
On Sat, Oct 01, 2022 at 18:10:19 +0200, Stefan Kangas wrote:
> Eli Zaretskii <eliz@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 18:11 ` Alan Mackenzie
@ 2022-10-01 21:15 ` Alan Mackenzie
2022-10-02 5:59 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-01 21:15 UTC (permalink / raw)
To: Stefan Kangas; +Cc: acm, Eli Zaretskii, 58224
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@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).
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-01 21:15 ` Alan Mackenzie
@ 2022-10-02 5:59 ` Eli Zaretskii
2022-10-02 10:43 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-10-02 5:59 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: stefankangas, 58224
> Date: Sat, 1 Oct 2022 21:15:46 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 58224@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 5:59 ` Eli Zaretskii
@ 2022-10-02 10:43 ` Alan Mackenzie
2022-10-02 11:04 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-02 10:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, stefankangas, 58224
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@gnu.org>, 58224@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 10:43 ` Alan Mackenzie
@ 2022-10-02 11:04 ` Eli Zaretskii
2022-10-02 11:32 ` Alan Mackenzie
2022-10-02 15:38 ` Alan Mackenzie
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-10-02 11:04 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: acm, stefankangas, 58224
> Date: Sun, 2 Oct 2022 10:43:44 +0000
> Cc: stefankangas@gmail.com, 58224@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 11:04 ` Eli Zaretskii
@ 2022-10-02 11:32 ` Alan Mackenzie
2022-10-02 15:38 ` Alan Mackenzie
1 sibling, 0 replies; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-02 11:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, stefankangas, 58224
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@gmail.com, 58224@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 11:04 ` Eli Zaretskii
2022-10-02 11:32 ` Alan Mackenzie
@ 2022-10-02 15:38 ` Alan Mackenzie
2022-10-02 15:54 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-02 15:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, 58224
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@gmail.com, 58224@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 15:38 ` Alan Mackenzie
@ 2022-10-02 15:54 ` Eli Zaretskii
2022-10-02 16:46 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-10-02 15:54 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: stefankangas, 58224
> Date: Sun, 2 Oct 2022 15:38:25 +0000
> Cc: stefankangas@gmail.com, 58224@debbugs.gnu.org
> From: Alan Mackenzie <acm@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 15:54 ` Eli Zaretskii
@ 2022-10-02 16:46 ` Alan Mackenzie
2022-10-02 17:07 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-02 16:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, stefankangas, 58224
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@gmail.com, 58224@debbugs.gnu.org
> > From: Alan Mackenzie <acm@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 16:46 ` Alan Mackenzie
@ 2022-10-02 17:07 ` Eli Zaretskii
2022-10-02 20:37 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-10-02 17:07 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: acm, stefankangas, 58224
> Date: Sun, 2 Oct 2022 16:46:01 +0000
> Cc: stefankangas@gmail.com, 58224@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 17:07 ` Eli Zaretskii
@ 2022-10-02 20:37 ` Alan Mackenzie
2022-10-02 21:29 ` Stefan Kangas
0 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2022-10-02 20:37 UTC (permalink / raw)
To: Eli Zaretskii, stefankangas; +Cc: acm, 58224-done
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@gmail.com, 58224@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file"
2022-10-02 20:37 ` Alan Mackenzie
@ 2022-10-02 21:29 ` Stefan Kangas
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Kangas @ 2022-10-02 21:29 UTC (permalink / raw)
To: Alan Mackenzie, Eli Zaretskii; +Cc: 58224-done
Alan Mackenzie <acm@muc.de> writes:
> I've committed a patch, and I'm closing the bug with this post.
Thanks! It works great.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-10-02 21:29 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-01 14:15 bug#58224: 29.0.50; "make bootstrap" spuriously warns: "comp.el newer than byte-compiled file" Stefan Kangas
2022-10-01 14:29 ` Lars Ingebrigtsen
2022-10-01 14:50 ` Eli Zaretskii
2022-10-01 16:10 ` Stefan Kangas
2022-10-01 18:11 ` Alan Mackenzie
2022-10-01 21:15 ` Alan Mackenzie
2022-10-02 5:59 ` Eli Zaretskii
2022-10-02 10:43 ` Alan Mackenzie
2022-10-02 11:04 ` Eli Zaretskii
2022-10-02 11:32 ` Alan Mackenzie
2022-10-02 15:38 ` Alan Mackenzie
2022-10-02 15:54 ` Eli Zaretskii
2022-10-02 16:46 ` Alan Mackenzie
2022-10-02 17:07 ` Eli Zaretskii
2022-10-02 20:37 ` Alan Mackenzie
2022-10-02 21:29 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).