all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#9106: 24.0.50; ./configure causes massive recompilation
@ 2011-07-17  5:30 Eli Zaretskii
  2011-07-18 17:48 ` Glenn Morris
                   ` (4 more replies)
  0 siblings, 5 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-17  5:30 UTC (permalink / raw)
  To: 9106

Invocation of the `configure' script causes recompilation of many
source files, even though nothing has really changed.

It looks like the cause is lib/Makefile which states that several
generated headers in that directory depend on config.status.  So each
`configure' causes those headers to be regenerated, which in turn
triggers many files using those headers to be recompiled.

This is annoying, as building Emacs even on a modern system takes a
significant amount of time (about 3 minutes on this box, whose details
see below).  Can this annoyance be removed, please?


In GNU Emacs 24.0.50.22 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-07-17 on fencepost
configured using `configure  '--with-gif=no' '--with-tiff=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
B ESC O A ESC O A ESC O A C-x C-f C h a n g TAB RET 
ESC [ 5 ~ ESC [ 5 ~ ESC [ 6 ~ ESC [ 6 ~ ESC [ 6 ~ ESC 
[ 6 ~ ESC O B ESC O B ESC O B ESC O B ESC O B ESC O 
B ESC O B ESC O B ESC O B ESC O B ESC O B ESC O B ESC 
O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C 
ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC 
O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C 
ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC 
O C ESC O C ESC O C ESC O B ESC O B ESC O B ESC O B 
ESC O B ESC O B ESC O B ESC O B ESC O B ESC O B ESC 
O B ESC O B ESC O B ESC O B ESC O B ESC O A ESC O A 
ESC O A ESC O A C-x b I N B TAB RET C-u g m a i l . 
n e w RET m e m a c s - d e v e l @ g n u . o r g DEL 
DEL DEL DEL DEL DEL DEL DEL SPC DEL @ g n u . o r g 
ESC O B ESC ~ C-x 5 o ESC x r e p o r t - e m TAB 
RET

Recent messages:
scroll-down-command: Beginning of buffer [2 times]
Getting mail from /srv/data/home/e/eliz/mail.new...
Counting new messages...
Counting messages...60
Counting new messages...done (70)
Saving file /home/e/eliz/INBOX...
Wrote /home/e/eliz/INBOX [2 times]
Computing summary lines...done
70 new messages read
Modification-flag cleared

Load-path shadows:
None found.

Features:
(shadow emacsbug sendmail flyspell ispell add-log vc-bzr cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt qp rmailsum rmailmm message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader mail-parse rfc2231 rmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time paren cus-start cus-load
time-date savehist saveplace tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process
dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  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   ` Eli Zaretskii
  2011-07-20  0:39 ` Paul Eggert
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 29+ messages in thread
From: Glenn Morris @ 2011-07-18 17:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106

Eli Zaretskii wrote:

> Invocation of the `configure' script causes recompilation of many
> source files, even though nothing has really changed.

Why do you want to re-run configure - can you get away with just `make'?
In principle, almost anything could have changed if you have re-run
configure (?). Eg you could in principle be compiling for a different
arch now. I'm not sure it's possible to distinguish those cases from
cases where nothing has really changed.

> It looks like the cause is lib/Makefile which states that several
> generated headers in that directory depend on config.status.  So each
> `configure' causes those headers to be regenerated, which in turn
> triggers many files using those headers to be recompiled.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  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:37   ` Eli Zaretskii
  1 sibling, 1 reply; 29+ messages in thread
From: Jan Djärv @ 2011-07-18 18:20 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9106



Glenn Morris skrev 2011-07-18 19.48:
> Eli Zaretskii wrote:
>
>> Invocation of the `configure' script causes recompilation of many
>> source files, even though nothing has really changed.
>
> Why do you want to re-run configure - can you get away with just `make'?
> In principle, almost anything could have changed if you have re-run
> configure (?). Eg you could in principle be compiling for a different
> arch now. I'm not sure it's possible to distinguish those cases from
> cases where nothing has really changed.

'make' after a bzr upd often runs configure nowdays.  More often than not.

	Jan D.

>
>> It looks like the cause is lib/Makefile which states that several
>> generated headers in that directory depend on config.status.  So each
>> `configure' causes those headers to be regenerated, which in turn
>> triggers many files using those headers to be recompiled.
>
>





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2011-07-18 17:48 ` Glenn Morris
  2011-07-18 18:20   ` Jan Djärv
@ 2011-07-18 18:37   ` Eli Zaretskii
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-18 18:37 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9106

> From: Glenn Morris <rgm@gnu.org>
> Cc: 9106@debbugs.gnu.org
> Date: Mon, 18 Jul 2011 13:48:45 -0400
> 
> Eli Zaretskii wrote:
> 
> > Invocation of the `configure' script causes recompilation of many
> > source files, even though nothing has really changed.
> 
> Why do you want to re-run configure - can you get away with just `make'?

How can I know?  I just did a "bzr up", and I don't want to analyze
every file that got updated to see if a mere "make" will do.  E.g.,
what if some Makefile.in got updated?

It used to be the case that if the results of running `configure'
didn't change anything of essence, "make" would do nothing.  This
worked by producing the generated files under temporary names and by
using move-if-change to overwrite the old files if the new ones were
different.  Why cannot we extend this method to the additional files
we generate now?

> In principle, almost anything could have changed if you have re-run
> configure (?). Eg you could in principle be compiling for a different
> arch now. I'm not sure it's possible to distinguish those cases from
> cases where nothing has really changed.

Of course, it's possible: several files, such as src/config.h, will be
different.  We just need to compare them before we overwrite the old
ones with new.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2011-07-18 18:20   ` Jan Djärv
@ 2011-07-18 18:37     ` Glenn Morris
  2011-07-18 18:58       ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Glenn Morris @ 2011-07-18 18:37 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 9106

Jan Djärv wrote:

> 'make' after a bzr upd often runs configure nowdays.  More often than not.

Then I guess the prerequisites of configure (the various Makefile.in's
etc) must be being updated a lot right now. I don't see a way round
this. Re-running configure is The Right Thing.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2011-07-18 18:37     ` Glenn Morris
@ 2011-07-18 18:58       ` Eli Zaretskii
  0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-18 18:58 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9106

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  9106@debbugs.gnu.org
> Date: Mon, 18 Jul 2011 14:37:04 -0400
> 
> Jan Djärv wrote:
> 
> > 'make' after a bzr upd often runs configure nowdays.  More often than not.
> 
> Then I guess the prerequisites of configure (the various Makefile.in's
> etc) must be being updated a lot right now. I don't see a way round
> this. Re-running configure is The Right Thing.

I have nothing against re-running configure.  I just don't want it
unnecessarily compiling things.






^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  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-20  0:39 ` Paul Eggert
       [not found] ` <4E2623CA.8090805@cs.ucla.edu>
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 29+ messages in thread
From: Paul Eggert @ 2011-07-20  0:39 UTC (permalink / raw)
  To: 9106; +Cc: bug-gnulib

[cc'ing bug-gnulib as it's related; see <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9106>]

> It used to be the case that if the results of running `configure'
> didn't change anything of essence, "make" would do nothing.  This
> worked by producing the generated files under temporary names and by
> using move-if-change to overwrite the old files if the new ones were
> different.

If memory serves, that process is pretty error-prone.  One can't
simply use move-if-change: one needs a separate time stamp file for
each file that one is doing the move-if-change trick with.  Otherwise,
when you run 'make' again, it will cheerfully regenerate all the .h
files again.  And with the time stamp files, one runs into problems
where the time stamp files are out of sync with reality.

I'm not saying it can't be done, but it would be a pain to have it
done without losing reliability during the build.  Part of the problem
is deciding automatically whether a change is one "of essence".





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found] ` <4E2623CA.8090805@cs.ucla.edu>
@ 2011-07-20  5:24   ` Eli Zaretskii
       [not found]   ` <E1QjPH2-0000Dw-03@fencepost.gnu.org>
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-20  5:24 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 9106, bug-gnulib

> Date: Tue, 19 Jul 2011 17:39:38 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: bug-gnulib <bug-gnulib@gnu.org>
> 
> [cc'ing bug-gnulib as it's related; see <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9106>]
> 
> > It used to be the case that if the results of running `configure'
> > didn't change anything of essence, "make" would do nothing.  This
> > worked by producing the generated files under temporary names and by
> > using move-if-change to overwrite the old files if the new ones were
> > different.
> 
> If memory serves, that process is pretty error-prone.  One can't
> simply use move-if-change: one needs a separate time stamp file for
> each file that one is doing the move-if-change trick with.  Otherwise,
> when you run 'make' again, it will cheerfully regenerate all the .h
> files again.

Sorry, I don't see the difficulty.  Perhaps I'm missing something.

The current recipe for producing, e.g., unistd.h from unistd.in.h is
this:

  unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H)
	  $(AM_V_GEN)rm -f $@-t $@ && \
	  { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
	    sed -e 's|@''GUARD_PREFIX''@|GL|g' \
	    [...]
		-e '/definition of _GL_WARN_ON_USE/r $(WARN_ON_USE_H)'; \
	  } > $@-t && \
	  mv $@-t $@

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, but as
long as that file isn't copied over unistd.h, the source files that
include unistd.h won't be recompiled.  Regeneration of unistd.h-t is
very fast; it's the needless recompilation of the plethora of source
files that include unistd.h that is the problem addressed by this bug
report.

It could be the case that some configure.in wizardry would resolve
this even nicer, by doing a similar move-if-change trick with
config.status (whose being a prerequisite of these header files is the
trigger for their regeneration, IIUC).  That will prevent even the
regeneration itself.  But I don't know if this is possible without too
much effort, so the suggested simpler "band-aid" is good enough for
me.

> Part of the problem is deciding automatically whether a change is
> one "of essence".

I think comparing the old file with the new one, like move-if-change
does, is all that's needed.  There's no requirement to detect changes
that are non-essential, like comments etc. -- if any change is
detected, let the files be recompiled.  Am I missing something?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]   ` <E1QjPH2-0000Dw-03@fencepost.gnu.org>
@ 2011-07-20  5:58     ` Paul Eggert
       [not found]     ` <4E266E98.4010901@cs.ucla.edu>
  1 sibling, 0 replies; 29+ messages in thread
From: Paul Eggert @ 2011-07-20  5:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106, bug-gnulib

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.  And this would occur
every time one does a 'make', even when there's no real work
to do.

The unnecessary "make" actions would fill up people's screens,
and would be confusing.  I'm afraid this cure would be worse
than the disease.






^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]     ` <4E266E98.4010901@cs.ucla.edu>
@ 2011-07-20  6:29       ` Eli Zaretskii
       [not found]       ` <E1QjQHq-0003DH-6Q@fencepost.gnu.org>
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-20  6:29 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 9106, bug-gnulib

> 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.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [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>
  2 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-20  6:38 UTC (permalink / raw)
  To: eggert; +Cc: 9106, bug-gnulib

> Date: Wed, 20 Jul 2011 02:29:38 -0400
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9106@debbugs.gnu.org, bug-gnulib@gnu.org
> 
> > 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.

Perhaps you thought that a mere "make", even without re-running
`configure', will trigger these rules.  But that is not the case: as
long as config.status is not updated, these rules will not be
triggered, since unistd.h etc. will always be newer than the
corresponding *.in.h templates, due to the fact that move-if-change
_will_ overwrite them with newer versions whenever there's a real
change in the *.in.h templates.

Am I missing something?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [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>
  2 siblings, 0 replies; 29+ messages in thread
From: Ralf Wildenhues @ 2011-07-20  6:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106, Paul Eggert, bug-gnulib

Hello,

* Eli Zaretskii wrote on Wed, Jul 20, 2011 at 08:29:38AM CEST:
> > From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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.

Yes, but 'make' is run a lot more often than 'configure' in some
workflows.  I think one implicit gnulib expectation is that configure
is not run often.  (FWIW I don't agree, because if your source tree
is several times larger than your gnulib extract, then it really matters
whether you need to rebuild the world even rarely.)

I proposed using stamp files before, but there are (understandable)
reservations against them.

Cheers,
Ralf





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]         ` <E1QjQQK-0003x0-Db@fencepost.gnu.org>
@ 2011-07-20  6:46           ` Ralf Wildenhues
       [not found]           ` <20110720064623.40890@gmx.net>
  1 sibling, 0 replies; 29+ messages in thread
From: Ralf Wildenhues @ 2011-07-20  6:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106, eggert, bug-gnulib

* Eli Zaretskii wrote on Wed, Jul 20, 2011 at 08:38:24AM CEST:
> > > 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.
> 
> Perhaps you thought that a mere "make", even without re-running
> `configure', will trigger these rules.  But that is not the case: as
> long as config.status is not updated, these rules will not be
> triggered, since unistd.h etc. will always be newer than the
> corresponding *.in.h templates, due to the fact that move-if-change
> _will_ overwrite them with newer versions whenever there's a real
> change in the *.in.h templates.
> 
> Am I missing something?

I think you are.  Once config.status is updated, the .h files' rules
are triggered, but since move-if-change never updates identical outputs
they will be triggered every time from then on.

You need a separate stamp file to avoid this.

Cheers,
Ralf





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]           ` <20110720064623.40890@gmx.net>
@ 2011-07-20  8:48             ` Eli Zaretskii
  0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-20  8:48 UTC (permalink / raw)
  To: Ralf Wildenhues; +Cc: 9106, eggert, bug-gnulib

> Cc: eggert@cs.ucla.edu, 9106@debbugs.gnu.org, bug-gnulib@gnu.org
> Date: Wed, 20 Jul 2011 08:46:23 +0200
> From: "Ralf Wildenhues" <Ralf.Wildenhues@gmx.de>
> 
> I think you are.  Once config.status is updated, the .h files' rules
> are triggered, but since move-if-change never updates identical outputs
> they will be triggered every time from then on.
> 
> You need a separate stamp file to avoid this.

Or use move-if-change with config.status.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]     ` <201107211257.44586.bruno@clisp.org>
@ 2011-07-21 20:59       ` Paul Eggert
       [not found]       ` <4E289329.1020204@cs.ucla.edu>
  2011-07-21 22:27       ` Jim Meyering
  2 siblings, 0 replies; 29+ messages in thread
From: Paul Eggert @ 2011-07-21 20:59 UTC (permalink / raw)
  To: Bruno Haible; +Cc: 9106, bug-gnulib, Ralf Wildenhues

On 07/21/11 03:57, Bruno Haible wrote:
> Is that the kind of rule you would recommend?

Yes, something like that might work, for config.status in Emacs.
But I'd rather not debug this sort of thing myself.
Like you, I'm leery of time stamp files; too often
their costs outweigh their benefits.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]       ` <4E289329.1020204@cs.ucla.edu>
@ 2011-07-21 21:27         ` Bruno Haible
       [not found]         ` <201107212327.27095.bruno@clisp.org>
  1 sibling, 0 replies; 29+ messages in thread
From: Bruno Haible @ 2011-07-21 21:27 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 9106, bug-gnulib, Ralf Wildenhues

Paul Eggert wrote:
> Like you, I'm leery of time stamp files; too often
> their costs outweigh their benefits.

What are, concretely, the problems you are fearing, or that you remember
from the past? In other words, which are the tests that we should perform
before committing a change that makes use of stamp files?

Bruno
-- 
In memoriam Ludwig Beck <http://en.wikipedia.org/wiki/Ludwig_Beck>





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]         ` <201107212327.27095.bruno@clisp.org>
@ 2011-07-21 22:00           ` Paul Eggert
       [not found]           ` <4E28A192.6010702@cs.ucla.edu>
  1 sibling, 0 replies; 29+ messages in thread
From: Paul Eggert @ 2011-07-21 22:00 UTC (permalink / raw)
  To: Bruno Haible; +Cc: 9106, bug-gnulib

On 07/21/11 14:27, Bruno Haible wrote:
> What are, concretely, the problems you are fearing, or that you remember
> from the past? In other words, which are the tests that we should perform
> before committing a change that makes use of stamp files?

Your earlier message summarized the problems that I remember.
(Perhaps I've forgotten some.)  I'm afraid that the only reliable
way to test changes in this area is to have many Emacs developers
and installers, who use different styles, build Emacs and report
the problems that they see.  This would be a reasonable thing to
do, if the benefit is large enough relative to the cost (something
that's not clear to me).





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]     ` <201107211257.44586.bruno@clisp.org>
  2011-07-21 20:59       ` Paul Eggert
       [not found]       ` <4E289329.1020204@cs.ucla.edu>
@ 2011-07-21 22:27       ` Jim Meyering
  2 siblings, 0 replies; 29+ messages in thread
From: Jim Meyering @ 2011-07-21 22:27 UTC (permalink / raw)
  To: Bruno Haible; +Cc: 9106, Paul Eggert, bug-gnulib

Bruno Haible wrote:
> Paul, Jim, Eric, others, do you remember other problems of stamp files?
>
>> The config.h rule (among others) has been using one for years,
>> and the last time I've heard complaints or bug reports about it
>> has been years also.
>
> For reference, here's the rules automake generates for config.h:
>
> config.h: stamp-h1
>         @if test ! -f $@; then \
>           rm -f stamp-h1; \
>           $(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
>         else :; fi
>
> stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
>         @rm -f stamp-h1
>         cd $(top_builddir) && $(SHELL) ./config.status config.h
>
> $(srcdir)/config.h.in:  $(am__configure_deps)
>         ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
>         rm -f stamp-h1
>         touch $@
>
> distclean-hdr:
>         -rm -f config.h stamp-h1
>
> Is that the kind of rule you would recommend?

Hi Bruno,

I know of no problem with that time stamp mechanism.
It's been in use (complaint-free) for a very long time.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]           ` <4E28A192.6010702@cs.ucla.edu>
@ 2011-07-22  6:14             ` Eli Zaretskii
       [not found]             ` <83zkk6u9ja.fsf@gnu.org>
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2011-07-22  6:14 UTC (permalink / raw)
  To: Paul Eggert; +Cc: bruno, 9106, bug-gnulib

> Date: Thu, 21 Jul 2011 15:00:50 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 9106@debbugs.gnu.org, bug-gnulib@gnu.org, 
>  Eli Zaretskii <eliz@gnu.org>
> 
> [...] if the benefit is large enough relative to the cost (something
> that's not clear to me).

People complain about bzr operations that take 15 seconds where git
takes 3, so I'm sure recovering 3 minutes of needless compilation will
be quite a win, at a cost of a couple of additional recipes in the
top-level Makefile.in.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
       [not found]             ` <83zkk6u9ja.fsf@gnu.org>
@ 2011-07-22  8:06               ` Paul Eggert
  0 siblings, 0 replies; 29+ messages in thread
From: Paul Eggert @ 2011-07-22  8:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: bruno, 9106, bug-gnulib

On 07/21/11 23:14, Eli Zaretskii wrote:
> I'm sure recovering 3 minutes of needless compilation will
> be quite a win, at a cost of a couple of additional recipes

If the only cost were two small make rules, that would indeed be a win.
I worry the cost will be larger than that.  But please feel free
to give it a try, and see.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2011-07-17  5:30 bug#9106: 24.0.50; ./configure causes massive recompilation Eli Zaretskii
                   ` (3 preceding siblings ...)
       [not found] ` <83k4bcvo1f.fsf@gnu.org>
@ 2022-04-25 10:40 ` Lars Ingebrigtsen
  2022-04-25 11:34   ` Eli Zaretskii
  4 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-25 10:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106

Eli Zaretskii <eliz@gnu.org> writes:

> Invocation of the `configure' script causes recompilation of many
> source files, even though nothing has really changed.
>
> It looks like the cause is lib/Makefile which states that several
> generated headers in that directory depend on config.status.  So each
> `configure' causes those headers to be regenerated, which in turn
> triggers many files using those headers to be recompiled.
>
> This is annoying, as building Emacs even on a modern system takes a
> significant amount of time (about 3 minutes on this box, whose details
> see below).  Can this annoyance be removed, please?

Reading this bug thread, it seems that various options were suggested
(mostly around different move-if-changed solutions), but they all seemed
to have various problems.

I think that it's unlikely that a user runs configure twice in a row
without changing any options, so I don't personally see any problems
with re-compiling all the .c files after running configure, so I wonder
whether there's really anything to be done here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 10:40 ` Lars Ingebrigtsen
@ 2022-04-25 11:34   ` Eli Zaretskii
  2022-04-25 12:10     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-04-25 11:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 9106

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 9106@debbugs.gnu.org
> Date: Mon, 25 Apr 2022 12:40:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Invocation of the `configure' script causes recompilation of many
> > source files, even though nothing has really changed.
> >
> > It looks like the cause is lib/Makefile which states that several
> > generated headers in that directory depend on config.status.  So each
> > `configure' causes those headers to be regenerated, which in turn
> > triggers many files using those headers to be recompiled.
> >
> > This is annoying, as building Emacs even on a modern system takes a
> > significant amount of time (about 3 minutes on this box, whose details
> > see below).  Can this annoyance be removed, please?
> 
> Reading this bug thread, it seems that various options were suggested
> (mostly around different move-if-changed solutions), but they all seemed
> to have various problems.
> 
> I think that it's unlikely that a user runs configure twice in a row
> without changing any options, so I don't personally see any problems
> with re-compiling all the .c files after running configure, so I wonder
> whether there's really anything to be done here.

I don't mind closing this as wontfix.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 11:34   ` Eli Zaretskii
@ 2022-04-25 12:10     ` Lars Ingebrigtsen
  2022-04-25 13:42       ` Robert Pluim
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-25 12:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9106

Eli Zaretskii <eliz@gnu.org> writes:

> I don't mind closing this as wontfix.

OK; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 12:10     ` Lars Ingebrigtsen
@ 2022-04-25 13:42       ` Robert Pluim
  2022-04-25 14:29         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Robert Pluim @ 2022-04-25 13:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 9106

>>>>> On Mon, 25 Apr 2022 14:10:30 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Eli Zaretskii <eliz@gnu.org> writes:
    >> I don't mind closing this as wontfix.

    Lars> OK; closing.

Hang on: what about

./configure
make
...configure gets run again, WTF?

Admittedly from a tree thatʼs been ./configure'd before (and I donʼt
really think I should need to run 'make clean' or 'make bootstrap'
here).

Robert
-- 





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 13:42       ` Robert Pluim
@ 2022-04-25 14:29         ` Lars Ingebrigtsen
  2022-04-25 15:49           ` Robert Pluim
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-25 14:29 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 9106

Robert Pluim <rpluim@gmail.com> writes:

> ./configure
> make
> ...configure gets run again, WTF?

Doesn't happen when I try that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 14:29         ` Lars Ingebrigtsen
@ 2022-04-25 15:49           ` Robert Pluim
  2022-04-25 16:13             ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Robert Pluim @ 2022-04-25 15:49 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 9106

>>>>> On Mon, 25 Apr 2022 16:29:09 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> ./configure
    >> make
    >> ...configure gets run again, WTF?

    Lars> Doesn't happen when I try that.

And now I canʼt reproduce it. Oh well.

Robert
-- 





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 15:49           ` Robert Pluim
@ 2022-04-25 16:13             ` Eli Zaretskii
  2022-04-26 15:43               ` Robert Pluim
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-04-25 16:13 UTC (permalink / raw)
  To: Robert Pluim; +Cc: larsi, 9106

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  9106@debbugs.gnu.org
> Date: Mon, 25 Apr 2022 17:49:40 +0200
> 
> >>>>> On Mon, 25 Apr 2022 16:29:09 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
> 
>     Lars> Robert Pluim <rpluim@gmail.com> writes:
>     >> ./configure
>     >> make
>     >> ...configure gets run again, WTF?
> 
>     Lars> Doesn't happen when I try that.
> 
> And now I canʼt reproduce it. Oh well.

Maybe you remembered doing "make bootstrap" after "configure", not
just "make".





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-25 16:13             ` Eli Zaretskii
@ 2022-04-26 15:43               ` Robert Pluim
  2022-05-05  8:33                 ` Robert Pluim
  0 siblings, 1 reply; 29+ messages in thread
From: Robert Pluim @ 2022-04-26 15:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 9106

>>>>> On Mon, 25 Apr 2022 19:13:35 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> Maybe you remembered doing "make bootstrap" after "configure", not
    Eli> just "make".

Thatʼs always a possibility. Iʼll pay more attention next time 😊

Robert
-- 





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#9106: 24.0.50; ./configure causes massive recompilation
  2022-04-26 15:43               ` Robert Pluim
@ 2022-05-05  8:33                 ` Robert Pluim
  0 siblings, 0 replies; 29+ messages in thread
From: Robert Pluim @ 2022-05-05  8:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 9106

>>>>> On Tue, 26 Apr 2022 17:43:18 +0200, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Mon, 25 Apr 2022 19:13:35 +0300, Eli Zaretskii <eliz@gnu.org> said:
    Eli> Maybe you remembered doing "make bootstrap" after "configure", not
    Eli> just "make".

    Robert> Thatʼs always a possibility. Iʼll pay more attention next time 😊

So this was actually

git pull
./configure
make
=> configure runs again

but thatʼs normal, since the git pull in this case updated
configure.ac, so it all working properly

Robert
-- 





^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2022-05-05  8:33 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
     [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

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.