unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 9106@debbugs.gnu.org, bug-gnulib@gnu.org
Subject: bug#9106: 24.0.50; ./configure causes massive recompilation
Date: Wed, 20 Jul 2011 02:29:38 -0400	[thread overview]
Message-ID: <E1QjQHq-0003DH-6Q__15569.8891882368$1311143447$gmane$org@fencepost.gnu.org> (raw)
In-Reply-To: <4E266E98.4010901@cs.ucla.edu> (message from Paul Eggert on Tue,  19 Jul 2011 22:58:48 -0700)

> Date: Tue, 19 Jul 2011 22:58:48 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 9106@debbugs.gnu.org, bug-gnulib@gnu.org
> 
> On 07/19/2011 10:24 PM, Eli Zaretskii wrote:
> > What I'm suggesting is to replace the last command ("mv $@-t $@") with
> > this:
> >
> >      move-if-change $@-t $@
> >
> > That's it.  Make will indeed cheerfully regenerate unistd.h-t
> 
> ... and alloca.h-t.  And getopt.h-t.  And the other ten .h-t files
> that are generated on typical platforms.

Yes.

> And this would occur every time one does a 'make', even when there's
> no real work to do.

This occurs already: these headers are regenerated every time I re-run
the `configure' script.  How is my suggestion worse than the current
situation?

> The unnecessary "make" actions would fill up people's screens,
> and would be confusing.

They fill up my screen already, as things are now.

> I'm afraid this cure would be worse than the disease.

I feel there's some kind of misunderstanding here, because with my
proposal, nothing will happen that doesn't already happen.  Perhaps
you could show in more detail which Make actions would happen that
doesn't happen now.





  parent reply	other threads:[~2011-07-20  6:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-17  5:30 bug#9106: 24.0.50; ./configure causes massive recompilation Eli Zaretskii
2011-07-18 17:48 ` Glenn Morris
2011-07-18 18:20   ` Jan Djärv
2011-07-18 18:37     ` Glenn Morris
2011-07-18 18:58       ` Eli Zaretskii
2011-07-18 18:37   ` Eli Zaretskii
2011-07-20  0:39 ` Paul Eggert
     [not found] ` <4E2623CA.8090805@cs.ucla.edu>
2011-07-20  5:24   ` Eli Zaretskii
     [not found]   ` <E1QjPH2-0000Dw-03@fencepost.gnu.org>
2011-07-20  5:58     ` Paul Eggert
     [not found]     ` <4E266E98.4010901@cs.ucla.edu>
2011-07-20  6:29       ` Eli Zaretskii [this message]
     [not found]       ` <E1QjQHq-0003DH-6Q@fencepost.gnu.org>
2011-07-20  6:38         ` Eli Zaretskii
2011-07-20  6:44         ` Ralf Wildenhues
     [not found]         ` <E1QjQQK-0003x0-Db@fencepost.gnu.org>
2011-07-20  6:46           ` Ralf Wildenhues
     [not found]           ` <20110720064623.40890@gmx.net>
2011-07-20  8:48             ` Eli Zaretskii
     [not found] ` <83k4bcvo1f.fsf@gnu.org>
     [not found]   ` <20110720210417.270150@gmx.net>
     [not found]     ` <201107211257.44586.bruno@clisp.org>
2011-07-21 20:59       ` Paul Eggert
     [not found]       ` <4E289329.1020204@cs.ucla.edu>
2011-07-21 21:27         ` Bruno Haible
     [not found]         ` <201107212327.27095.bruno@clisp.org>
2011-07-21 22:00           ` Paul Eggert
     [not found]           ` <4E28A192.6010702@cs.ucla.edu>
2011-07-22  6:14             ` Eli Zaretskii
     [not found]             ` <83zkk6u9ja.fsf@gnu.org>
2011-07-22  8:06               ` Paul Eggert
2011-07-21 22:27       ` Jim Meyering
2022-04-25 10:40 ` Lars Ingebrigtsen
2022-04-25 11:34   ` Eli Zaretskii
2022-04-25 12:10     ` Lars Ingebrigtsen
2022-04-25 13:42       ` Robert Pluim
2022-04-25 14:29         ` Lars Ingebrigtsen
2022-04-25 15:49           ` Robert Pluim
2022-04-25 16:13             ` Eli Zaretskii
2022-04-26 15:43               ` Robert Pluim
2022-05-05  8:33                 ` Robert Pluim

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='E1QjQHq-0003DH-6Q__15569.8891882368$1311143447$gmane$org@fencepost.gnu.org' \
    --to=eliz@gnu.org \
    --cc=9106@debbugs.gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    /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).