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

On Tue, Apr 14, 2020 at 08:06:14AM +0100, Harald van Dijk via Bug reports for autoconf wrote:
> 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.

Let me point out that, regarding timestumps, a lot of automake-using
software gets built on clusters, with not really well-maintained
toolchains, and on networked filesystems, which are usually not sufficiently
fast for correct clock synching. If AM_MAINTAINER_MODE is used with
default enable-maintainer-mode option, you usually get an obscure build
error from missing script. And if AM_MAINTAINER_MODE is not used,
following a rather unfortunate advise that it leads to (basically,
nowadays, absent) eventual problems, it's even worse, as you basically need to
patch the configure.ac on a system with working autotools toolchain,
ideally convince upstream that AM_MAINTAINER_MODE is not as bad so that
it gets properly fixed, etc etc.

(Quote: "Still many people continue to use AM_MAINTAINER_MODE, because it helps
them working on projects where all files are kept under version control,
and because missing isn’t enough if you have the wrong version of the
tools." - Do we need to discuss how much past century this is?)

While this is tangential to this thread, an update in the direction
rectifying this isssue would be very welcome.

Best,
Dmitrii
> 
> 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
>