Karl Berry wrote:
bh> Seen e.g. on NetBSD 10.0.Which doesn't support subsecond mtimes? jb> Maybe the best answer is to test for subsecond timestamp granularity first, and then only do the slow test to distinguish between 1-second and 2-second granularity if the subsecond granularity test gives a negative result? Unfortunately, that is already the case. The function (_AM_FILESYSTEM_TIMESTAMP_RESOLUTION in m4/sanity.m4) does the tests starting with .01, then .1, then 1. Searching for sleep [012] in Bruno's log confirms this.
So we are hitting the one-second timestamp granularity path because there is a modern system that does not have sub-second timestamp granularity, and that path is annoyingly slow.
If I understand correctly, Bruno's goal is to omit the "1" test if we can detect that we're not on a fat filesystem. But I admit I don't like trying to inspect filesystem types. That way lies madness, it seems to me, and this whole function is already maddening enough. E.g., mount and/or df could hang if NFS is involved.
I agree, although I had not considered the possibilities of problems with NFS.
It seems to me that using stat doesn't help because it's not available by default on the bsds etc., as Bruno pointed out.
Does BSD ls(1) support "--time=ctime --time-style=full-iso"? That would give equivalent information as stat(1) and, if at least one file has an odd seconds field, would rule out FAT quickly. It could also indicate one-second granularity, if all subsecond parts are zero. The slow test would still be required to confirm the worst case: all timestamps are even because the filesystem has 2-second timestamp granularity.
The simple change is to omit the make test if we are at resolution 1. That will save 4 seconds. Omitting it is justified because the make test is only there for the sake of makes that are broken wrt subsecond timestamps. I will do that.
If the critical issue is whether or not make(1) correctly handles subsecond timestamp granularity, why not simply test if make(1) recognizes subsecond timestamp differences and remove the other tests? If we are on a filesystem that does not have subsecond timestamp granularity, make will not have it either.
That will leave 2+ sec of sleeping, but if we are to reliably support fat, I don't see a good alternative. At least it's not as bad as 6+. Any other ideas?
As I hinted at, could we move the entire test into make(1) somehow? Could we lay out a set of files with timestamps differing by .01, .1, 1 seconds and then see which pairs have ages distinguishable by make(1)? That should complete in less than 2 seconds: 1.11 seconds to make the files and less than half a second to run make(1). If we can find a portable way to read timestamps to 1-second resolution, we can confirm not being on FAT---there will be one "odd file out" and the others will all have either odd or even timestamps. If the timestamps all match, we can assume 2-second granularity without further testing, or do the slow test to confirm it. If the "odd file out" has a timestamp two seconds ahead of the others, we *know* the filesystem has 2-second granularity and we crossed a "tick" boundary while making the files.
Alternately, could we improve the UI by emitting one additional dot per approximate second during the test? Reassure the user that, yes, configure is doing something, even if all we can actually do is wait for the clock to advance.
-- Jacob
