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
