Fixing the lisp/loaddefs.el situation

Fixing the lisp/loaddefs.el situation

[Miles Bader]

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]

Re: Fixing the lisp/loaddefs.el situation

[Frank Schmitt]

Miles Bader <miles@gnu.org> writes:

> 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).*
[...]
> Does anyone have any objection to this change?

I think this is an excellent idea, I hate it to have dozens of
#loaddefs.el.xxx files in my lisp folder resulting from conflicts when
merging.

Just one question: Will a simple "make" be enough to ensure that new
autoloads are recognized when building?

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Fixing the lisp/loaddefs.el situation

[David Ponce]

Hi Miles,

[...]
> 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).*
[...]

Looks good.  What about lisp/makefile-w32.in?

David

Re: Fixing the lisp/loaddefs.el situation

[Miles Bader]

David Ponce <david.ponce@wanadoo.fr> writes:
> Looks good.  What about lisp/makefile-w32.in?

I have no idea about that; a cursory glance shows lots of things
commented out from the normal makefile, and some weird shit to deal with
different command interpreter types, so I think it's best to leave it to
the experts (if there be any).

-miles
-- 
Fast, small, soon; pick any 2.

Re: Fixing the lisp/loaddefs.el situation

[Miles Bader]

OK, I've committed this change.

You'll probably have to do either a `make -C lisp autoloads' or
`make bootstrap' to get loaddefs.el back up to speed.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Fixing the lisp/loaddefs.el situation

[David PONCE]

Hi Miles,

>>Looks good.  What about lisp/makefile-w32.in?
> 
> 
> I have no idea about that; a cursory glance shows lots of things
> commented out from the normal makefile, and some weird shit to deal with
> different command interpreter types, so I think it's best to leave it to
> the experts (if there be any).

I propose you this patch for lisp/makefile.w32-in, took from your
changes to lisp/Makefile.in.  I managed to bootstrap today's CVS
version of Emacs on my Windows NT box, using latest MinGW 3.0.0-1
toolkit and the "sh" shell environment provided by cygwin.  Hope it
will help.

David

Index: lisp/makefile.w32-in
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/makefile.w32-in,v
retrieving revision 1.31
diff -c -r1.31 makefile.w32-in
*** lisp/makefile.w32-in	1 Sep 2003 15:45:13 -0000	1.31
--- lisp/makefile.w32-in	15 Sep 2003 06:39:05 -0000
***************
*** 87,92 ****
--- 87,93 ----
  	$(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 \
***************
*** 352,373 ****
  recompile: doit
  	$(emacs) -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.
  
  # Need separate version for sh and native cmd.exe
  bootstrap-clean: bootstrap-clean-$(SHELLTYPE) loaddefs.el
  
  bootstrap-clean-CMD:
  #	if exist $(EMACS) $(MAKE) $(MFLAGS) autoloads
  	-for %f in (. $(WINS)) do for %g in (%f\*.elc) do @$(DEL) %g
  
  bootstrap-clean-SH:
  #	if test -f $(EMACS); then $(MAKE) $(MFLAGS) autoloads; fi
  #	-rm -f $(lisp)/*.elc $(lisp)/*/*.elc
  	-for dir in . $(WINS); do rm -f $$dir/*.elc; done
  
  # Generate/update files for the bootstrap process.
--- 353,385 ----
  recompile: doit
  	$(emacs) -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.  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.
  
  # Need separate version for sh and native cmd.exe
  bootstrap-clean: bootstrap-clean-$(SHELLTYPE) loaddefs.el
  
  bootstrap-clean-CMD:
  #	if exist $(EMACS) $(MAKE) $(MFLAGS) autoloads
+ 	if not exist $(lisp)\loaddefs.el cp $(lisp)/loaddefs-boot.el $(lisp)/loaddefs.el
  	-for %f in (. $(WINS)) do for %g in (%f\*.elc) do @$(DEL) %g
  
  bootstrap-clean-SH:
  #	if test -f $(EMACS); then $(MAKE) $(MFLAGS) autoloads; fi
  #	-rm -f $(lisp)/*.elc $(lisp)/*/*.elc
+ 	if ! test -r $(lisp)/loaddefs.el; then \
+ 	  cp $(lisp)/loaddefs-boot.el $(lisp)/loaddefs.el; \
+ 	fi
  	-for dir in . $(WINS); do rm -f $$dir/*.elc; done
  
  # Generate/update files for the bootstrap process.

Re: Fixing the lisp/loaddefs.el situation

[Miles Bader]

David PONCE <david.ponce@wanadoo.fr> writes:
> I propose you this patch for lisp/makefile.w32-in, took from your
> changes to lisp/Makefile.in.

Thanks, it looks good to me, I'll add that change.

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Fixing the lisp/loaddefs.el situation

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 15 Sep 2003 15:38:17 +0900
> 
> OK, I've committed this change.
> 
> You'll probably have to do either a `make -C lisp autoloads' or
> `make bootstrap' to get loaddefs.el back up to speed.

I see one problem with this change: loaddefs.el and loaddefs-boot.el
map to the same name on 8+3 filesystems.  So loaddefs-boot.el should
be renamed to something like ldefs-boot.el or boot-loaddefs.el or
whatever.

Sorry for not catching this earlier.

Re: Fixing the lisp/loaddefs.el situation

[Miles Bader]

On Mon, Sep 22, 2003 at 07:46:07PM +0200, Eli Zaretskii wrote:
> I see one problem with this change: loaddefs.el and loaddefs-boot.el
> map to the same name on 8+3 filesystems.  So loaddefs-boot.el should
> be renamed to something like ldefs-boot.el or boot-loaddefs.el or
> whatever.

Are we still supporting 8+3 filesystems?  I ran `doschk' and it reports a
bunch of violations for emacs; certainly we could fix them, but it seems
worthwhile to consider whether it's worth the trouble anymore.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Fixing the lisp/loaddefs.el situation

[Eli Zaretskii]

> Date: Mon, 22 Sep 2003 18:50:38 -0400
> From: Miles Bader <miles@gnu.org>
> 
> Are we still supporting 8+3 filesystems?

Yes, AFAIK.  At least I don't recall any decisions on dropping that
support.

> I ran `doschk' and it reports a bunch of violations for emacs

Which ones, please?  I know about 2 files in lisp/mh-e, which I
reported to the maintainer and was told it will be fixed well before
the current HEAD goes into pretest.  If there are others, please tell.

> certainly we could fix them, but it seems worthwhile to consider
> whether it's worth the trouble anymore.

Since the support of 8+3 systems currently doesn't impose any
significant maintenance burden, I'd advise not to drop it yet.

Please also note that, due to quirks in the way Windows generates
short 8+3 aliases for long file names and supports both long and short
names in the same session, with certain system configurations
loaddefs-bootstrap.el and loaddefs.el could both point to the same
file even though there are no 8+3 limitations in the filesystem; thus
copying the former over the latter could overwrite the original file.
(The default Windows configuration should not have this problem, but
there are options in the Registry which, when set, can lead to such
problems.)  So keeping file names 8+3-unique is a good idea even if we
drop support for building Emacs on pure DOS machines.