bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#2151: 23.0.90; Building the 23.0.90 pretest recompiles Lisp files


From: Stefan Monnier
Subject: bug#2151: 23.0.90; Building the 23.0.90 pretest recompiles Lisp files
Date: Tue, 03 Feb 2009 16:24:54 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

> I feared you'd say that.  All I can say is that I think it's
> fundamentally wrong to have Lisp files compile as part of the build
> (Yes, I know we compile Leim files, presumably to conserve space in
> the tarball, but I think that's wrong, too.)  The result is that a
> successful build becomes less predictable, and we can no longer depend
> on having the same good .elc files on all platforms.

OTOH, I feel like it's fundamentally wrong to provide pre-built files in
our tarball.  It's also fundamentally wrong to have such very different
build-"rules" between the "checkout from CVS" and "untarred" cases.
It makes maintenance more difficult.

> (It is also a major headache for the DOS port, since lisp/Makefile
> needs a Unixy shell, and I always avoided requiring that for building
> an official release.)

Good point.  So removing the .elc files would require more work.

>> Getting make to understand the nature of the dependencies here is pretty
>> tricky, so you can get it to work right for the tarball or you can get
>> it to work right for the "cvs update" case, but it's pretty painful
>> to get it to work right in both cases.

> I think it shouldn't be too hard, and the ideas you suggested further
> in your mail are my evidence.

Have you tried it?  It seems to work OK for the "checkout from CVS"
case, so maybe it's a good solution.

> I don't think we need a bootstrap-emacs in a released version at all.
> We could add some file to the tarball, generated at make-dist time, to
> signal that bootstrap-emacs is not needed.  That file could actually
> be named `bootstrap-emacs', which should resolve the problem nicely
> (assuming we manage to have it older than the oldest .elc file).

Maybe we can get that to work, but it sounds terribly hackish.
Also, I'd like to make sure that if some wants to change some .el files
and then recompile, it still works correctly.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]