Re: [PATCH] up_to_date_p: treat equal mtime as outdated.
On 2020-04-13, Paul Eggert wrote: > 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 the Autoconf manual's portability notes are to be believed, then such a rule is really not a good idea because on filesystems suporting subsecond timestamp precision some "cp -p" implementations can create the destination file with a strictly older timestamp than the source. It's worth pointing out that even on filesystems supporting high- precision timestamps, actual mtime updates usually have significantly lower resolution (typically on the order of a millisecond or so). Sufficiently fast make rules can frequently create many files with exactly the same mtime. Therefore considering equal timestamps to be "up-to-date" is really the only reasonable option. In cases where it is required to create two files with distinct mtimes, the only real portable option I've found is to touch one of the files in a loop and compare timestamps until they are different. Cheers, Nick
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 >
Re: [PATCH] up_to_date_p: treat equal mtime as outdated.
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
