* 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).