[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23.0.60; bootstrap broken by removal of cal-loaddefs.el
From: |
Tim Van Holder |
Subject: |
Re: 23.0.60; bootstrap broken by removal of cal-loaddefs.el |
Date: |
Fri, 14 Mar 2008 13:12:14 +0100 |
On Fri, Mar 14, 2008 at 10:48 AM, Tim Van Holder
<address@hidden> wrote:
>
> Ever since the removal of cal-loaddefs from CVS, I had gotten lisp
> compilation errors during my more-or-less-daily rebuild. They seemed
> harmless enough (especially since I don't actually use the calendar),
> but this morning I decided to go for a full bootstrap to (hopefully)
> make them go away.
> Unfortunately, it looks like the bootstrap does not generate the file in
> time for the full lisp compilations, so I received
>
> Compiling /home/tim/gnu/src/emacs/lisp/./gnus/yenc.el
> Wrote /home/tim/gnu/src/emacs/lisp/gnus/yenc.elc
> Compiling /home/tim/gnu/src/emacs/lisp/./calendar/appt.el
>
> In toplevel form:
> ../../../../src/emacs/lisp/calendar/appt.el:79:1:Error: Cannot open load
> file: cal-loaddefs
> make[2]: *** [compile] Error 1
> make[2]: Leaving directory `/home/tim/gnu/build/linux/emacs/lisp'
> make[1]: *** [bootstrap-build] Error 2
> make[1]: Leaving directory `/home/tim/gnu/build/linux/emacs'
> make: *** [bootstrap] Error 2
>
> It's worked around easily enough (I just fetched the last version from
> CVS), but should probably be fixed.
>
>
> In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
> of 2008-03-14 on leeloo
> Windowing system distributor `RealVNC Ltd', version 11.0.3370
> configured using `configure '--with-x-toolkit=gtk' '--with-x'
> '--with-freetype' '--with-xft' '--with-libotf''
Sorry for replying to myself here, but the same goes for the two other calendar
loaddefs (diary-loaddefs and hol-loaddefs). They need to exist for
bootstrap to work,
and the bootstrap process does NOT regenerate them at any point (nor does a
"make recompile updates" in lisp/, which I run as part of my daily
rebuild-from-CVS).
So it looks as though the Makefile.in in lisp/ has not been correctly
instrumented to
create them.