Re: reproducible built files

[Bruno Haible]

Hi Paul,

> >    timestamp(Y) := max (vmtime(X1), vmtime(X2), ..., vmtime(Xn)).
> > 
> > where vmtime(X) is defined as:
> > 
> >     - if X is under version control and not modified locally:
> >       $(git log -1 --format=%ct X),
> >       that is, the last time file X was modified under version control,
> >     - otherwise: mtime(X).
> 
> This is roughly what I use for TZDB <https://iana.org/tz>, except with 
> the following additions:
> 
> * timestamp(Y) is 1 + max (...), not merely max (...). This is for 
> portability to 'make' implementations that consider equal timestamps to 
> mean that the target needs rebuilding (POSIX suggests this behavior).
> 
> * If X is built and is not under version control, then vmtime(X) is 
> timestamp(X) not mtime(X). This is needed for reproducibility when there 
> are long dependency chains.

Thanks for mentioning this.
Re 1 + max: yes that makes sense, also for compensating a conversion
   to entire seconds, that loses fractional seconds.
Re chains: yes, that makes sense as well. In my case, this applies to
   the po/POTFILES file, which is generated from po/POTFILES.in. The
   vmtime(po/POTFILES) needs to be ignored; the vmtime(po/POTFILES.in)
   is what matters instead.

I see your rules in tz/Makefile, target 'set-timestamps.out'. This rule uses
"git diff --quiet $$file". Shouldn't it use "git diff --quiet HEAD $$file"
instead? I.e. treat a modification that was staged via "git add FILE" like a
modification that was not staged?

Bruno