From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Fixing the lisp/loaddefs.el situation Date: 13 Sep 2003 11:01:12 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <874qzhcuqf.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063418645 3839 80.91.224.253 (13 Sep 2003 02:04:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2003 02:04:05 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Sep 13 04:04:03 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19xzlb-0004jO-00 for ; Sat, 13 Sep 2003 04:04:03 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 19xzn8-0004aV-00 for ; Sat, 13 Sep 2003 04:05:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19xzjj-0007Lc-6r for emacs-devel@quimby.gnus.org; Fri, 12 Sep 2003 22:02:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19xzjd-0007KQ-IO for emacs-devel@gnu.org; Fri, 12 Sep 2003 22:02:01 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19xzjb-0007Jw-Nh for emacs-devel@gnu.org; Fri, 12 Sep 2003 22:02:00 -0400 Original-Received: from [203.216.5.131] (helo=smtp01.fields.gol.com) by monty-python.gnu.org with esmtp (Exim 4.22) id 19xzjb-0007JN-0O; Fri, 12 Sep 2003 22:01:59 -0400 Original-Received: from filter01.fields.gol.com ([203.216.5.148] helo=localhost) by smtp01.fields.gol.com with esmtp (Magnetic Fields) id 19xzjY-0004wZ-O3; Sat, 13 Sep 2003 11:01:56 +0900 Original-Received: from yokohama1-61-203-152-59.ap.0038.net ([61.203.152.59] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp01.fields.gol.com with asmtp (Magnetic Fields) id 19xzjX-0004wW-Cm; Sat, 13 Sep 2003 11:01:55 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id 2DBCF2F2C; Sat, 13 Sep 2003 11:01:13 +0900 (JST) Original-To: emacs-devel@gnu.org System-Type: i686-pc-linux-gnu Original-Lines: 96 X-Virus-Scanned: by AMaViS X-Abuse-Complaints: abuse@gol.com X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16355 lisp/loaddefs.el is a pain because it's both in the CVS repository _and_ a commonly regenerated file, meaning that it shows up as being modified by `cvs update' and will be committed if you do `cvs commit' (even if nothing of substance changed, there usually seems to be enough noise to cause this). Not only is this messy, it can be very aggravating for users with slow network connections -- cvs has the annoying property of sending the entire contents of changed files to the server (so the server can compute the delta), and loaddefs.el is a pretty big file. I've fixed this by renaming `loaddefs.el' to `loaddefs-boot.el', and changing lisp/Makefile.in to copy the former from the latter when necessary (basically during bootstrap-clean, only if there's no existing loaddefs.el, and no emacs binary to build it with).* Because this change will remove loaddefs.el from the repository, cvs will delete it from working directories when doing a `cvs update', so it will be necessary for people to either do `make -C lisp autoloads' or `make bootstrap' or something. Does anyone have any objection to this change? Thanks, -Miles * added files lisp/loaddefs-boot.el * modified files --- orig/lisp/Makefile.in +++ mod/lisp/Makefile.in @@ -80,6 +80,7 @@ $(lisp)/language/utf-8-lang.el \ $(lisp)/language/georgian.el \ $(lisp)/loaddefs.el \ + $(lisp)/loaddefs-boot.el \ $(lisp)/loadup.el \ $(lisp)/mail/blessmail.el \ $(lisp)/patcomp.el \ @@ -186,11 +187,11 @@ $(emacs) -f batch-update-authors $(srcdir)/AUTHORS $(srcdir) TAGS: $(lisptagsfiles1) $(lisptagsfiles2) - els=`echo $(lisptagsfiles1) $(lisptagsfiles2) | sed -e "s,$(lisp)/loaddefs.el,,"`; \ + els=`echo $(lisptagsfiles1) $(lisptagsfiles2) | sed -e "s,$(lisp)/loaddefs.*\.el,,"`; \ ${ETAGS} $$els TAGS-LISP: $(lisptagsfiles1) $(lisptagsfiles2) - els=`echo $(lisptagsfiles1) $(lisptagsfiles2) | sed -e "s,$(lisp)/loaddefs.el,,"`; \ + els=`echo $(lisptagsfiles1) $(lisptagsfiles2) | sed -e "s,$(lisp)/loaddefs.*\.el,,"`; \ ${ETAGS} -o TAGS-LISP $$els .SUFFIXES: .elc .el @@ -274,14 +275,27 @@ recompile: doit $(EMACS) $(EMACSOPT) -f batch-byte-recompile-directory $(lisp) -# Prepare a bootstrap in the lisp subdirectory. Build loaddefs.el, -# because it's not sure it's up-to-date, and if it's not, that might -# lead to errors during the bootstrap because something fails to -# autoload as expected. Remove compiled Lisp files so that -# bootstrap-emacs will be built from sources only. +# Prepare a bootstrap in the lisp subdirectory. +# +# Build loaddefs.el, because it's not sure it's up-to-date, and if it's not, +# that might lead to errors during the bootstrap because something fails to +# autoload as expected. However, if there is no emacs binary, then we can't +# build autoloads yet, so just make sure there's some loaddefs.el file, as +# it's necessary for generating the binary (because loaddefs.el is an +# automatically generated file, we don't want to store it in the source +# repository). +# +# Remove compiled Lisp files so that bootstrap-emacs will be built from +# sources only. bootstrap-clean: - if test -x $(EMACS); then $(MAKE) $(MFLAGS) autoloads; fi + if test -x $(EMACS); then \ + $(MAKE) $(MFLAGS) autoloads; \ + else \ + if ! test -r $(lisp)/loaddefs.el; then \ + cp $(lisp)/loaddefs-boot.el $(lisp)/loaddefs.el; \ + fi \ + fi cd $(lisp); rm -f *.elc */*.elc # Generate/update files for the bootstrap process. -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist]