GNU bug report logs - #17407
obsolete-autoloads can clobber regular autoloads

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

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

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

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: obsolete-autoloads can clobber regular autoloads
Date: Mon, 05 May 2014 03:21:46 -0400

Package: emacs
Version: 24.4.50

Have an up-to-date build of current trunk:

cd lisp
make autoloads
cp loaddefs.el loaddefs.el.BAK
echo ";;foo" >> mail/rmailsum.el
make autoloads

diff loaddefs.el.BAK loaddefs.el
  - see that all the rmail.el autoloads have vanished

I believe this explains the failure in http://hydra.nixos.org/build/10824210 .

Analysis:

The batch-update-autoloads in `make autoload' extracts autoloads from
rmailsum.el into rmail.el, modifying the hash in the latter and the
file's timestamp. It then calles `make obsolete-autoloads'.
This calls batch-update-autoloads again. This notices that rmail.el has
a changed timestamp, so rescans it for autoloads. Because
generate-autoload-cookie is set to a non-standard value, it finds none,
so it erases them all from loaddefs.el.

I don't understand why `obsolete-autoloads' is scanning rmail.el, when
it calls "-f batch-update-autoloads ${lisp}/obsolete".
Why isn't it just restricting itself to scanning obsolete/, as instructed?

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

From: Glenn Morris <rgm <at> gnu.org>
To: 17407 <at> debbugs.gnu.org
Subject: Re: bug#17407: obsolete-autoloads can clobber regular autoloads
Date: Mon, 05 May 2014 13:56:20 -0400

PS irrespective of obsolete-autoloads, it seems like a potential problem
that `make autoloads' might leave you with a loaddefs.el that is not
strictly up-to-date. If it scans rmail.el first and adds its entry to
loaddefs.el, then scans rmailsum.el and so modifies rmail.el, the
rmail.el entry in loaddefs.el will have an outdated timestamp. So if you
immediately run `make autoloads' again, loaddefs.el will change.

Perhaps if when scanning file B, file A gets modified, it should go back
and update the stored timestamp of file A, if previously scanned.

Previous Next

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