From: Glenn Morris <rgm@gnu.org>
To: 48181@debbugs.gnu.org
Cc: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#48181: incremental autoloads update can put output in wrong file
Date: Sun, 02 May 2021 21:08:57 -0400 [thread overview]
Message-ID: <9fpmy8fwt2.fsf@fencepost.gnu.org> (raw)
Package: emacs
Version: 28.0.50
I tried to figure out exactly why 68bf917896 caused non-bootstrap builds
to fail, because IIUC in theory it shouldn't have. I think this is why:
1) before 68bf917896, lisp/loaddefs.el contains sections like this:
;;;### (autoloads nil "texnfo-upd" "textmodes/texnfo-upd.el" (0 0
;;;;;; 0 0))
;;; Generated autoloads from textmodes/texnfo-upd.el
(register-definition-prefixes "texnfo-upd" '("texinfo-"))
So even though there aren't any real autoloads in texnfo-upd.el, it's
not in the "no autoloads" section.
2) 68bf917896 added real autoload cookies to texnfo-upd.el, and set
generated-autoload-file to texinfo-loaddefs.el.
3) make-directory-autoloads correctly finds that texnfo-upd.el is newer
than loaddefs.el, so we execute this branch:
(t
(setq changed t)
(autoload-remove-section (match-beginning 0))
(if (autoload-generate-file-autoloads
;; Passing `current-buffer' makes it insert at point.
file (current-buffer) buffer-file-name)
(push file no-autoloads)))
Because a non-nil OUTBUF is passed to autoload-generate-file-autoloads,
it ignores the buffer-local setting for generated-autoload-file,
and so puts the autoloads in the main loaddefs.el file, which is wrong.
In contrast, if the input loaddefs.el file in step 1 had texnfo-upd.el
in the "no loaddefs" section, then we would execute this branch:
;; Passing nil as second argument forces
;; autoload-generate-file-autoloads to look for the right
;; spot where to insert each autoloads section.
((setq file-time
(autoload-generate-file-autoloads file nil buffer-file-name))
As the comment says, this version has OUTBUF nil, so the loaddefs end up
the right file.
next reply other threads:[~2021-05-03 1:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-03 1:08 Glenn Morris [this message]
2021-05-03 11:37 ` bug#48181: incremental autoloads update can put output in wrong file Eli Zaretskii
2021-05-03 12:49 ` Stefan Monnier
2022-06-05 16:31 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fpmy8fwt2.fsf@fencepost.gnu.org \
--to=rgm@gnu.org \
--cc=48181@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).