Re: generated version numbers

[Harlan Stenn]

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