Re: lisp/emacs-lisp/cl-loaddefs.el in git archive

[Ken Raeburn]

On Aug 1, 2009, at 15:43, Randal L. Schwartz wrote:
> The file lisp/emacs-lisp/cl-loaddefs.el in the git archive is  
> problematic,
> because a file cannot be both a tracked source and a build-output in  
> git.
> Each build updates the file, thus dirtying the tree, requiring it to  
> be
> checked in before a fetch or pull.

It looks like it's storing md5 sums of the input files.  Which means  
it'll be regenerated, but it's repeatable.  Checking in the updated cl- 
loaddefs.el when one of the other files is changed (in this case  
apparently cl-macs.el) should keep things in sync.  Depending on  
timestamps and makefile dependencies and such, it may still get  
rebuilt in the next build after an update, but the content will be  
unchanged.

In fact it's probably more stable than lisp/loaddefs.el (which appears  
to use input file timestamps?) or configure (which is dependent on the  
version of autoconf installed).  Rebuild those and you may well not  
get the content to match the repository, though functionally it'll  
probably be the same.  I usually just throw away mine in favor of the  
one from the repository, unless I've actually made some changes.

> Ahh, it appears that something is using it before it would have been  
> created
> or updated.

Kind of like "configure".

>  This would appear to be a build bug.  Can someone who is more
> familiar with this process help me understand why this is the way it  
> is, so I
> can sort it out for the git archive?

It's cached information from the various input elisp files, that  
doesn't change often, and takes a while to reconstruct. For  
distribution it should speed things up in end-user builds, vs  
processing all the elisp files for autoloads then.  In the case of  
loaddefs.el, there's also a bootstrapping issue -- that's the file  
that tells Emacs where functions like update-directory-autoloads are  
to be found.

I suspect it would be possible to make the files at build time, by  
explicitly indicating where to load the Lisp code necessary code for  
generating them, or using some non-Lisp mechanism for generating  
them.  Or even scan all the files during loadup before dumping, but I  
think that would generate excessive garbage taking up space in the new  
image, and it'd mean rerunning the whole thing any time you make a  
change to one of the Emacs C source files and recompile.

We have a few other generated files in the repository, like the  
configure script.  It usually hasn't been a big problem, as long as  
the files get updated when necessary.

Ken