bug#17407: obsolete-autoloads can clobber regular autoloads

bug#17407: obsolete-autoloads can clobber regular autoloads

[Glenn Morris]

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?

bug#17407: obsolete-autoloads can clobber regular autoloads

[Glenn Morris]

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.