From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, Andreas Schwab <schwab@linux-m68k.org>,
Stefan Monnier <monnier@IRO.UMontreal.CA>,
rms@gnu.org
Subject: Re: Annoyingly cautious make rules
Date: Sat, 03 Dec 2011 13:52:45 +0900 [thread overview]
Message-ID: <877h2e2r4y.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <4ED917E2.7020807@cs.ucla.edu>
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.
next prev parent reply other threads:[~2011-12-03 4:52 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 [this message]
2011-12-03 20:34 ` Paul Eggert
2011-12-03 9:23 ` Richard Stallman
2011-12-03 4:26 ` Stephen J. Turnbull
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=877h2e2r4y.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--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).