Re: File-specific autoloads

[Thien-Thi Nguyen <ttn@gnuvola.org>]

() Eli Zaretskii <eliz@gnu.org>
() Fri, 06 Jul 2007 19:04:53 +0300

   That's an incorrect emulation of what "make autoloads" does: it _does_
   modify the file.  At least in my case, it did (I verified that with
   "cvs diff").

that's fine (no argument).  we discuss that case below:

   > but regardless of cvs version quirks, let's look at the nature of the
   > changes: autoload processing changes a specified region; programmers
   > should not change that region manually.

   And we want to rely on that?

we want to rely on it inasmuch as we designed it that way.  if our design
changes so that mixing autoload-processing regions and programmer regions is
encouraged, then that would influence our downstream reliance.  however, i see
from cvs annotate autoload.el:

1.58         (rms      05-Aug-97): (defvar generated-autoload-file "loaddefs.el"
1.58         (rms      05-Aug-97):    "*File \\[update-file-autoloads] puts autoloads into.
1.58         (rms      05-Aug-97): A `.el' file can set this in its local variables section to make its
1.71         (kwzh     27-Jun-99): autoloads go somewhere else.  The autoload file is assumed to contain a
1.71         (kwzh     27-Jun-99): trailer starting with a FormFeed character.")

which leads me to believe that autoload processing is not prone to any radical
changes since it has worked for quite a while now (i could be wrong).

   Anyway, seeing those "M ps-print.el" lines in the output of "cvs up"
   is extremely annoying, because I'm used to take that as a sign that I
   have uncommitted changes in my sandbox.  It also breaks the principle
   that files that are rewritten locally as part of the build process are
   not kept in CVS.

these are separate issues that should be addressed separately.  one
approach to resolve the M status would be to request maintainers to
regenerate and check in their newest ps-print.el or cl-loaddefs.el
(regenerated) whenever any of the files that they serve as the autoload
file for are changed.  this is similar to the convention of checking in
configure (regenerated) as well as configure.in.

   So I think this change in its current incarnation is for the worse.
   Maybe if the autoloads were written into files that are not in CVS
   I'd be happier.

cvs already contains one generated file (configure script) and possibly
others.  i personally dislike that practice as well, but since we have
already done the head-scratching for that file, we might as well apply
the lessons to this situation.

thi