Hi Peter, Peter Johansson writes: > On 02/27/2014 04:47 AM, Harlan Stenn wrote: >> So while the filestamps are technically correct, the generated >> Makefile *will* see that version.m4 is newer than config.h.in and >> regenerate it via Makefile dependencies. >> >> I suspect the answer is that at the end of the bootstrap script, if >> the aclocal.m4 file is newer than the config.h.in file we need to >> touch the config.h.in file. > > File 'config.h.in' is generated by autoheader [I assume]. Autoheader > will not touch the time-stamp of 'config.h.in' if the content doesn't > change. This can be annoying, and is the reason Automake generated rule > has a 'touch $@' after autoheader is called > > $(srcdir)/config.h.in: $(am__configure_deps) > ($(am__cd) $(top_srcdir) && $(AUTOHEADER)) > rm -f stamp-h1 > touch $@ > > In my bootstrap script I issue autoreconf with option '--force', so I > don't see this problem. If you think that is too expensive, you could > set environment > variable AUTOHEADER with something like: > > AUTOHEADER="autoheader -f" autoreconf -vi > > Changing the behaviour of autoheader, I suspect will be met by some > significant resistance. Yes, understood. And the problem is that am__configure_deps includes am__aclocal_m4_deps, which includes aclocal.m4. So we have a case where as a result of autoreconf running, aclocal.m4 gets updated and config.h.in does not get updated. But the resulting directory will require autotools (apparently the 'missing' stuff is insufficient) because make *will* force a rebuild of config.h.in because aclocal.m4 is newer. So perhaps autoreconf needs a late test that if aclocal.m4 is newer than config.h.in, we touch config.h.in . This way, if nothing is updated then nothing gets touched. But if aclocal.m4 gets updated we'll avoid this particular problem. I think. This stuff is, of course, intricate. H _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
