On Wed, Feb 19, 2020 at 11:06 AM David Kastrup <d...@gnu.org> wrote: > Han-Wen Nienhuys <hanw...@gmail.com> writes: > > > On Wed, Feb 19, 2020 at 10:03 AM David Kastrup <d...@gnu.org> wrote: > > > >> > >> > So the dependency isn't correctly satisfied and we would always run it > >> > from then on, effectively slowing down our build system. And that is > >> > why I don't want to deal with this kind of issues - this should come > >> > with the build system for free. > >> > >> Well, since we have our own build system, making it come for free is > >> sort of our own job. > >> > >> > > I think it's easier if we give up on intelligence here, and just > recommend > > ccache. > > That does not seem like much of a help for the problem case at hand.
Autoconf tries to leave the config.h alone, using content based checks. I assume it does this because touching config.h triggers an expensive global recompile in timestamp-based build systems, like make. Our GNUmakefile tries to detect changes to config.h.in using timestamps, but autconf (see above) won't overwrite the file unless it really changed, so the default doesn't do the right thing. Our comment says: # this is to prevent people from getting # undefined symbols when we add them to config.h.in, # and they blindly run "cvs update; make". the mention of CVS shows you how old this comment is. My proposal is to have configure always regenerate config.h, because ccache makes the full rebuild almost free, so we don't need configure's cleverness. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
