unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Annoyingly cautious make rules
Date: Sat, 03 Dec 2011 13:26:13 +0900	[thread overview]
Message-ID: <878vmu2sd6.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <83ehwnc97k.fsf@gnu.org>

Eli Zaretskii writes:
 > > From: Andreas Schwab <schwab@linux-m68k.org>
 > > Date: Fri, 02 Dec 2011 13:13:32 +0100
 > > Cc: emacs-devel@gnu.org
 > > 
 > > Richard Stallman <rms@gnu.org> writes:
 > > 
 > > > The cache used to be enabled automatically.  How do you enable it now?

 > Why is the default OFF?

Because *persistently* caching information about system configurations
is a very bad idea, *especially* a GNU system.  (I don't think I've
ever had an Emacs build break due to a Linux upgrade, so I'll leave
Linux out of this. :-)  I would guess I have to rebuild my stable
Emacsen about once a month because some library "just disappears" (ie,
the SO version gets bumped and the old library gets removed because my
local Emacs builds don't have dependencies recorded in portage) in a
Gentoo upgrade, and they won't run at all.  I would imagine subtle
changes that should be reconfirmed by configure are happening almost
daily.

This is especially useful in the case of occasional beta testers, who
(like me) tend to upgrade system utilities a lot and get bit by such
issues all the time.  Emacs evidently has a more complex process and
needs the bootstrap stage which is more costly than XEmacs's "start
from scratch" process, but in XEmacs the biggest improvement we made
in the process for testers to get a clean build first time after
pulling new code into their source tree was disabling the cache.

This can be a bit annoying for developers who don't work on configure
(of course those of us who do work on configure need to run it often) 
but developers know how to type "./configure --help" and/or send mail
to the dev list, so we shouldn't need to worry about them too much.

It's a different matter if you do a lot of recursive configuration, of
course.  Then the cache is the way you communicate that checks have
already been done to configure subprocesses.  XEmacs does very little
so disabling the cache is obviously TRT.  I don't know about Emacs (I
just run "./configure && make" and go teach class :-).



      parent reply	other threads:[~2011-12-03  4:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30 21:48 Annoyingly cautious make rules Richard Stallman
2011-11-30 22:00 ` Paul Eggert
2011-12-01 21:54   ` Richard Stallman
2011-12-02  1:35     ` Stefan Monnier
2011-12-02 10:00     ` Paul Eggert
2011-12-01  3:54 ` Eli Zaretskii
2011-12-01  8:50 ` Andreas Schwab
2011-12-02 12:05   ` Richard Stallman
2011-12-02 12:11     ` Andy Wingo
2011-12-02 12:13     ` Andreas Schwab
2011-12-02 14:57       ` Eli Zaretskii
2011-12-02 15:05         ` Andreas Schwab
2011-12-02 15:41           ` Eli Zaretskii
2011-12-03  9:23           ` Richard Stallman
2011-12-02 16:14         ` Stefan Monnier
2011-12-02 16:24           ` Eli Zaretskii
2011-12-02 18:24           ` Paul Eggert
2011-12-02 18:39             ` Glenn Morris
2011-12-02 20:21               ` Paul Eggert
2011-12-02 20:36             ` Stefan Monnier
2011-12-02 21:29               ` Paul Eggert
2011-12-02 23:26                 ` Stefan Monnier
2011-12-03  0:34                 ` Andreas Schwab
2011-12-03  2:52                   ` Paul Eggert
2011-12-03  3:42                     ` Stefan Monnier
2011-12-03  3:55                       ` Paul Eggert
2011-12-03  5:48                         ` Stefan Monnier
2011-12-03  6:35                           ` Paul Eggert
2011-12-03  8:49                     ` Andreas Schwab
2011-12-03 20:15                       ` Paul Eggert
2011-12-03 20:29                         ` Andreas Schwab
2011-12-03 20:42                         ` Glenn Morris
2011-12-04 15:04                           ` Richard Stallman
2011-12-04 16:55                             ` Stefan Monnier
2011-12-04 18:57                               ` Paul Eggert
2011-12-05  2:53                                 ` Glenn Morris
2011-12-03  6:45                 ` Eli Zaretskii
2011-12-03 20:23               ` Paul Eggert
2011-12-03  4:52             ` Stephen J. Turnbull
2011-12-03 20:34               ` Paul Eggert
2011-12-03  9:23           ` Richard Stallman
2011-12-03  4:26         ` Stephen J. Turnbull [this message]

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=878vmu2sd6.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=schwab@linux-m68k.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).