* lisp/emacs-lisp/cl-loaddefs.el in git archive
@ 2009-08-01 19:43 Randal L. Schwartz
2009-08-01 22:08 ` Ken Raeburn
2009-08-04 17:18 ` Stefan Monnier
0 siblings, 2 replies; 3+ messages in thread
From: Randal L. Schwartz @ 2009-08-01 19:43 UTC (permalink / raw)
To: emacs-devel
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.
Does the file need to exist in the git archive? It looks to be a generated
file.
[time passes, trying an experiment of removing it first]
Ahh, it appears that something is using it before it would have been created
or updated. 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?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: lisp/emacs-lisp/cl-loaddefs.el in git archive
2009-08-01 19:43 lisp/emacs-lisp/cl-loaddefs.el in git archive Randal L. Schwartz
@ 2009-08-01 22:08 ` Ken Raeburn
2009-08-04 17:18 ` Stefan Monnier
1 sibling, 0 replies; 3+ messages in thread
From: Ken Raeburn @ 2009-08-01 22:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: lisp/emacs-lisp/cl-loaddefs.el in git archive
2009-08-01 19:43 lisp/emacs-lisp/cl-loaddefs.el in git archive Randal L. Schwartz
2009-08-01 22:08 ` Ken Raeburn
@ 2009-08-04 17:18 ` Stefan Monnier
1 sibling, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2009-08-04 17:18 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: emacs-devel
> Each build updates the file,
I suspect that's only an impression of yours. If not, it's a bug.
Yes, some builds update the file, but not "each".
> Does the file need to exist in the git archive?
For bootstrapping reasons, it's convenient to have it in the archive.
> It looks to be a generated file.
It is a generated file, indeed.
> Ahh, it appears that something is using it before it would have been
> created or updated. 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?
We could probably get rid of all those files (including ldefs-boot.el),
but nobody has tried yet, AFAIK.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-08-04 17:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-01 19:43 lisp/emacs-lisp/cl-loaddefs.el in git archive Randal L. Schwartz
2009-08-01 22:08 ` Ken Raeburn
2009-08-04 17:18 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.