secondary loaddefs [was Re: Bootstrap broken betweeen ...]

[Glenn Morris]

Stefan Monnier wrote:

>> Yes, I think that sounds like a good idea -- I have no idea why rmail
>> has its own loaddefs in the first place.
>
> Usually it's done for autoloads that are only used internally to
> a package so as to reduce the number of "useless" autoloads in
> loaddefs.el (and along with it, the size of Emacs's pdump heap).
>
> Looking at `rmail-loaddefs.el` I suspect there's a good chance that the
> problem can be fixed by adding the `noerror` to `require` so it doesn't
> signal an error when `rmail-loaddefs.el` is not found.  This will still
> work fine since those autoloads seem to all be for interactive commands
> which will only ever be used once an rmail buffer has been displayed to
> the user, i.e. long after we're done compiling Emacs.

Indeed. I wish people would give others a chance to explain before
changing things.

This arrangement isn't specific to rmail, and is used by eg calc,
ibuffer, dired, for many years.

Some history:

Originally such autoloads were hand-written. This is inefficient; eg
you don't get the doc-strings unless you manually copy them to the
autoload, and then you have two places to keep in sync.

Then the feature of allowing a file to specify a local
generated-autoload-file was added. At first this was used to
automatically add the autoloads into (eg) rmail.el in place of the
handwritten ones. update_autogen could automatically update these blocks.

However, people did not like this approach, because they would
sometimes see local modifications (different hashes) in versioned
files like rmail.el after building. So it was changed to have the
autoloads in a separate file that was not versioned, eg rmail-loaddefs.el.