[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#9106: 24.0.50; ./configure causes massive recompilation
Date: Wed, 20 Jul 2011 01:24:44 -0400

> Date: Tue, 19 Jul 2011 17:39:38 -0700
> From: Paul Eggert <address@hidden>
> Cc: bug-gnulib <address@hidden>
> [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

  unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) 
          $(AM_V_GEN)rm -f address@hidden $@ && \
          { 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)'; \
          } > address@hidden && \
          mv address@hidden $@

What I'm suggesting is to replace the last command ("mv address@hidden $@") with

    move-if-change address@hidden $@

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]