all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andreas Schwab <schwab@linux-m68k.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Eli Zaretskii <eliz@gnu.org>,
	emacs-devel@gnu.org, Stefan Monnier <monnier@IRO.UMontreal.CA>,
	rms@gnu.org
Subject: Re: Annoyingly cautious make rules
Date: Sat, 03 Dec 2011 09:49:18 +0100	[thread overview]
Message-ID: <m2fwh2avld.fsf@igel.home> (raw)
In-Reply-To: <4ED98EED.5020301@cs.ucla.edu> (Paul Eggert's message of "Fri, 02 Dec 2011 18:52:29 -0800")

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 12/02/11 16:34, Andreas Schwab wrote:
>> you must rerun configure anyway when it changes, not matter how you
>> update it.  This has nothing to do with maintainer mode.
>
> Yes, and that was the point I was trying to make (evidently I was
> not clear enough): the main 2011-03-20 changes are independent of
> maintainer mode, and these changes do not motivate making
> maintainer mode the default for ordinary builds.

I don't understand.  It is vital that configure is up-to-date
wrt. configure.in.  That's what the rule does, nothing more, nothing
less.  Before the change, the committer of configure.in had to commit
configure as well, to keep it updated.  Now this is done by make the
next time it is run.  The outcome is exactly the same, except that now
you are guaranteed that configure is up-to-date wrt. configure.in,
whereas before that change you were dependent on the one who changed
configure.in (who often didn't update configure as well, and also caused
a lot of version churn do to different autoconf versions).  So the
current situation is a overall win, but it didn't really change in a
substantial way.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



  parent reply	other threads:[~2011-12-03  8:49 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 [this message]
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

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

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

  git send-email \
    --in-reply-to=m2fwh2avld.fsf@igel.home \
    --to=schwab@linux-m68k.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=rms@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.