> Date: Tue, 19 Jul 2011 17:39:38 -0700 > From: Paul Eggert <egg...@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?