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:52:45 +0900 Message-ID: <877h2e2r4y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83ehwnc97k.fsf@gnu.org> <4ED917E2.7020807@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1322887991 17803 80.91.229.12 (3 Dec 2011 04:53:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2011 04:53:11 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Andreas Schwab , Stefan Monnier , rms@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 05:53:06 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 1RWhaz-00045r-Q7 for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2011 05:53:05 +0100 Original-Received: from localhost ([::1]:59136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhay-0002X8-FV for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2011 23:53:04 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:40468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhav-0002Ws-SC for emacs-devel@gnu.org; Fri, 02 Dec 2011 23:53:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWhau-0001Vp-Tt for emacs-devel@gnu.org; Fri, 02 Dec 2011 23:53:01 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:53033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWhat-0001Uh-3s; Fri, 02 Dec 2011 23:52:59 -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 99A5E9707AA; Sat, 3 Dec 2011 13:52:45 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 931841A274F; Sat, 3 Dec 2011 13:52:45 +0900 (JST) In-Reply-To: <4ED917E2.7020807@cs.ucla.edu> 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:146451 Archived-At: Paul Eggert writes: > On 12/02/11 08:14, Stefan Monnier wrote: > > IIUC it's because the expectation is that it's not run very often and > > that current machines are fast enough to make it bearable, > > Both assumptions are false for me. But the assumption that you can find "configure -C" easily is true, no? Let's optimize the default for the people for whom doing the wrong thing can be quite expensive. It costs you and Richard minutes waiting for configure, and from a few seconds to a day to learn about "-C", but it can cost an occasional tester days if their build breaks and they have no idea that it's a configure bug rather than a real build issue. > And another part of this problem is that "configure -C" is poorly > publicized. (Perhaps -C should be the default, but that's a bigger > change.) It used to be default. But for reasons given elsewhere, that really sucked for people who should *never* need to worry about autoconf's foot-shooting proclivities. It took years to get that changed. > Here's a patch that addresses the above issues, without making > -C the default. Thank you! > --- INSTALL.BZR 2011-06-25 17:51:03 +0000 > +++ INSTALL.BZR 2011-12-02 17:54:11 +0000 > @@ -26,7 +26,7 @@ > You can then configure your build (use `./configure --help' to see > options you can set): > > - $ ./configure > + $ ./configure -C Please, no. "-C" is an heuristic, not an optimization. Write this instead: You can then configure your build (use `./configure --help' to see options you can set): $ ./configure (If you run configure often, it can be annoyingly slow. You can use "./configure -C" to enable a cache, which does speed things up dramatically, but at the cost of correctness: your build *will* break occasionally over a period of months if you use "-C".) BTW, in $ ./configure -C $ ./configure does the second configure step read the cache? Does it leave an existing cache behind? > -echo "You can now run \`./configure'." > +echo "You can now run \`./configure -C'." Please, no. "-C" is an heuristic, not an optimization. It should be available to those who need it, but advertising it is inviting trouble for the testers and the folks who help testers on this list and others.