bug#9106: 24.0.50; ./configure causes massive recompilation

[Eli Zaretskii <eliz@gnu.org>]

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