Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

[Harald van Dijk]

On 14/04/2020 04:34, Paul Eggert wrote:
> On 4/13/20 4:21 PM, Harald van Dijk wrote:
> > For better or worse, FAT is the most universally accepted file system, 
> > and for that reason it is widely used. It does not even support second 
> > precision timestamps.
>
> Let's not worry much about that. In practice, little development of 
> Automake-using software occurs on FAT file systems, and even if it did 
> those file systems are low priority for GNU development.

It's by no means the only file system without sub-second timestamps 
though. I went with FAT because it is so widely used, but if you want a 
more UNIXy example, there's ext2/ext3, isn't there? Sub-second precision 
is one of the new features of ext4.

> I just checked, and GNU Make uses high-resolution file timestamps when 
> available, and considers a file to be up-to-date if it has exactly the 
> same timestamp as its dependency. I suspect that this is because 
> Makefile rules like this:
>
> a: b
>      cp -p b a
>
> would otherwise cause needless work if one ran 'make; make'. > > If Automake 
> followed the same rule as GNU Make, we'd at least have the
> benefit of consistency....

I suspect it's not (or not just) because of that, but because of rules 
that depend on generated files making it extremely likely that in 
practice you will see rules that are executed within a second of deps 
being modified. This is a tradeoff between correctness and avoiding 
unnecessary updates where autoconf/automake are not in the same 
situation as make. There are three things to consider:

1. Given a dep and target with equal mtime, how likely is it that the 
target is up to date?

2. Given a dep and target with equal mtime, if the target is up to date, 
what are the consequences of treating it as out of date?

3. Given a dep and target with equal mtime, if the target is out of 
date, what are the consequences of treating it as up to date?

My assumptions would be that 1 is more likely for make than it is for 
autoconf/automake (given that autoconf/automake are generally not using 
generated files as deps), that 2 is more harmful for make than it is for 
autoconf/automake (given command sequences such as make VAR=value && 
make install, where a spurious recompile during make install is not 
harmless but causes the effect of VAR=value to be lost), and that 3 is 
equally bad for make as it is for autoconf/automake.

Cheers,
Harald van Dijk