From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Annoyingly cautious make rules Date: Sat, 03 Dec 2011 13:26:13 +0900 Message-ID: <878vmu2sd6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83ehwnc97k.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1322886413 7289 80.91.229.12 (3 Dec 2011 04:26:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2011 04:26:53 +0000 (UTC) Cc: Andreas Schwab , rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 05:26:49 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RWhBZ-000478-7S for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2011 05:26:49 +0100 Original-Received: from localhost ([::1]:55201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhBY-0006nF-E8 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2011 23:26:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhBV-0006mz-4d for emacs-devel@gnu.org; Fri, 02 Dec 2011 23:26:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWhBU-0006dI-5Z for emacs-devel@gnu.org; Fri, 02 Dec 2011 23:26:45 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:48151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhBS-0006ar-2t; Fri, 02 Dec 2011 23:26:42 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C63709707CA; Sat, 3 Dec 2011 13:26:13 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B22C21A274F; Sat, 3 Dec 2011 13:26:13 +0900 (JST) In-Reply-To: <83ehwnc97k.fsf@gnu.org> X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 2dbefd79b3d3 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146450 Archived-At: Eli Zaretskii writes: > > From: Andreas Schwab > > Date: Fri, 02 Dec 2011 13:13:32 +0100 > > Cc: emacs-devel@gnu.org > > > > Richard Stallman 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 :-).