Re: 1.16.90 regression: configure now takes 7 seconds to start

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