unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Current CVS doesn't bootstrap
Date: Sun, 7 Nov 2004 11:43:41 -0600 (CST)	[thread overview]
Message-ID: <200411071743.iA7Hhfi01732@raven.dms.auburn.edu> (raw)
In-Reply-To: <01c4c487$Blat.v2.2.2$d4c31400@zahav.net.il> (eliz@gnu.org)

Eli Zaretskii wrote:

   > We either have to document in INSTALL.CVS that you have to do `make
   > maintainer-clean' before `make bootstrap' or we have to make sure
   > that `make bootstrap' removes the .elc files automatically, as it
   > used to do.

   I don't think this is the right solution.  First, either
   maintainer-clean or removing *.elc files causes the next bootstrap to
   run much longer, so we should avoid that as much as we could.
   Ideally, "make maintainer-clean" should be used only if "make
   bootstrap" fails (and that is something that we should add to
   INSTALL.CVS _right_now_).

Most of the time the problems caused by omitting `make maintainer-clean'
are not that bootstrapping fails, but that various bugs occur while
running the bootstrapped Emacs.  Usually, people have not the slightest
idea that these bugs are caused by failure to run `make maintainer-clean'.
I remember having seen many examples of fake bug reports caused by this.

I have a 1.7 dual Xeon.  That was a pretty fast machine when I bought
it three years ago, but today, just about any computer I see
advertised is faster and you can easily get something twice as fast.
On my machine, the entire:

make maintainer-clean
./configure
make bootstrap

takes less than 15 minutes.  Omitting the `make maintainer-clean'
probably saves about 7 of those 15 minutes and (to me) that is not
worth worrying about the potential bugs it introduces.  It are 7
minutes of my computer's time, not of my time.  I noticed on several
sites that many people are _trying_ to do the above procedure, but are
using `make-distclean', mistakenly believing that it will do what
`make maintainer-clean' does.

I realize that on older machines, and especially on operating systems
that can only run one process at a time, the situation may be very
different.

I propose, for now, the following patch to INSTALL.CVS.  Andreas'
proposed change would eliminate one of the three problems listed in
that patch, but not the two others.  I do not know whether that list
is exhaustive.  (I would guess not).

If the last added paragraph would seem to long or technical, it could
be replaced by one line saying: "`make distclean' is not a valid
substitute for `make maintainer-clean'".

===File ~/INSTALL.CVS-diff==================================
*** INSTALL.CVS	02 Apr 2004 12:04:32 -0600	1.3
--- INSTALL.CVS	07 Nov 2004 10:44:55 -0600	
***************
*** 11,19 ****
  The bootstrap process makes sure all necessary files are rebuilt
  before it builds the final Emacs binary.
  
  Normally, it is not necessary to use "make bootstrap" after every CVS
! update.  Unless there are problems, we suggest the following
! procedure:
  
    $ ./configure
    $ make
--- 11,23 ----
  The bootstrap process makes sure all necessary files are rebuilt
  before it builds the final Emacs binary.
  
+ The best way to proceed after a CVS update depends on how fast or busy
+ your computer is, whether your operating system can run more than one
+ job at a time and on how badly you want to avoid potential bugs.
+ 
  Normally, it is not necessary to use "make bootstrap" after every CVS
! update.  Thus, if you have a slow computer, or if you can only run one
! process at a time, we suggest the following procedure:
  
    $ ./configure
    $ make
***************
*** 39,44 ****
--- 43,73 ----
  
  If either of above procedures fails, try "make bootstrap".
  
+ If this still fails, do:
+ 
+ make maintainer-clean
+ ./configure
+ make bootstrap
+ 
+ You may also want to do this if you report bugs that other people can
+ not reproduce.  In fact, if you have a reasonably fast computer that
+ can run more than one process at a time you may always want to do the
+ above straight away, as it is the only way to be totally sure that
+ your Emacs is completely up to date.  However, `make maintainer-clean'
+ can slow down `make bootstrap' considerably on slower computers.
+ 
+ `make maintainer-clean' removes all .elc files, so that the subsequent
+ `make bootstrap' will recompile them.  Note that just doing `make
+ distclean' does not do this.  Even without prior `make maintainer-clean',
+ `make bootstrap' will automatically recompile all files whose .elc
+ file is newer than their .el files.  But this does not prevent all
+ problems.  For instance, problems arise when a file requires an out of
+ date file that has not been recompiled yet, when changes to byte
+ compiling are made, when the file that should be loaded is actually
+ older than the wrong file and similar situations.  All C files are
+ automatically recompiled by all procedures listed above, so there is
+ no need to worry about them.
+ 
  Users of non-Posix systems (MS-Windows etc.) should run the
  platform-specific configuration scripts (nt/configure.bat, config.bat,
  etc.) before "make bootstrap" or "make"; the rest of the procedure is
============================================================

  reply	other threads:[~2004-11-07 17:43 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-06 11:25 Current CVS doesn't bootstrap Eli Zaretskii
2004-11-06 14:16 ` Andreas Schwab
2004-11-06 14:40 ` Andreas Schwab
2004-11-06 16:16   ` Eli Zaretskii
2004-11-06 22:48     ` Luc Teirlinck
2004-11-07  0:35       ` Andreas Schwab
2004-11-07  1:25         ` Luc Teirlinck
2004-11-07  1:45           ` Andreas Schwab
2004-11-07  2:42             ` Satyaki Das
2004-11-07  3:15               ` Luc Teirlinck
2004-11-07  1:33         ` Luc Teirlinck
2004-11-07  2:07           ` Andreas Schwab
2004-11-07 18:04         ` Richard Stallman
2004-11-07 18:55           ` Luc Teirlinck
2004-11-07 22:10             ` Luc Teirlinck
2004-11-08 16:58               ` Richard Stallman
2004-11-07 23:26             ` Kim F. Storm
2004-11-07 23:45               ` Luc Teirlinck
2004-11-08  7:27                 ` Eli Zaretskii
2004-11-09  0:50                   ` Luc Teirlinck
2004-11-07  5:07       ` Eli Zaretskii
2004-11-07 17:43         ` Luc Teirlinck [this message]
2004-11-07 18:25           ` Han Boetes
2004-11-07 19:05             ` Luc Teirlinck
2004-11-07 18:38           ` David Kastrup
2004-11-07 19:33             ` Luc Teirlinck
2004-11-07 19:42               ` David Kastrup
2004-11-07 20:21                 ` Luc Teirlinck
2004-11-08  0:15                   ` Robert J. Chassell
2004-11-07 20:34               ` Piet van Oostrum
2004-11-07 20:37               ` Piet van Oostrum
2004-11-07 21:09                 ` Luc Teirlinck
2004-11-07 21:20                 ` Luc Teirlinck
2004-11-07 22:28           ` Eli Zaretskii
2004-11-07 23:05             ` Luc Teirlinck
2004-11-08  1:32             ` Lennart Borgman
2004-11-08  8:22               ` Eli Zaretskii
2004-11-14 21:20                 ` Lennart Borgman
2004-11-08  2:03             ` Luc Teirlinck
2004-11-08  2:31               ` Luc Teirlinck
2004-11-08  7:20               ` Eli Zaretskii
2004-11-08 17:16             ` Drew Adams
2004-11-08 19:07               ` Stefan Monnier
2004-11-07 18:07         ` Luc Teirlinck
2004-11-07 18:47         ` Luc Teirlinck
  -- strict thread matches above, loose matches on Subject: below --
2005-02-14 11:12 Andreas Schwab
2005-02-14 12:51 ` Lute Kamstra
2005-02-14 13:36 ` Reiner Steib
2005-02-15 17:27   ` Richard Stallman
2005-02-15 20:56     ` Reiner Steib
2005-02-17 10:35       ` Richard Stallman
2005-02-15 17:27 ` Richard Stallman
2005-02-15 19:12   ` Lute Kamstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200411071743.iA7Hhfi01732@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).