dherr...@tentpost.com wrote:
At some point, it becomes unreasonable to burden common platforms with
delays that only support relatively obscure and obsolete platforms.
Configure scripts already have a bad reputation for wasting time.
Even if they are faster than editing a custom makefile, they are idle
instead of active time for the user, so waiting is harder.
I feel that 6-second test delays or 2-second incremental delays later
qualify as clearly unreasonable. The 1-second timestamps are
borderline unreasonable. Cross-compiling with a decent filesystem is
more reasonable.
One second timestamp granularity is classic POSIX, and apparently also
modern NetBSD. We must support it.
Why can't we resolve this by requiring systems with 2-second
resolution to set a flag in config.site? That moves the burden closer
to where it belongs.
First, because configure scripts are supposed to Just Work without
particular expertise on the part of the user. (Users with such
deficient systems are least likely to have the expertise to handle
that.) Second, because timestamp resolution is actually per-volume,
which in the POSIX model, means it varies by directory. You can even
have a modern filesystem (with nanosecond granularity) mounted on a
directory in a FAT filesystem (with two second granularity) and
ultimately a root filesystem with one second granularity.
In fact, the machine on which I type this has all three: any tmpfs has
nanosecond resolution, but /home has been carried for many years since
mkfs and has one-second resolution, and I have removable media that is
formatted FAT with its infamous two-second resolution. All of these,
when in use, appear in the same hierarchical filesystem namespace.
-- Jacob
