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 >
