Karl Berry wrote:
Jacob,
[*sigh*]
You said it. About this whole thing. I rather wish this bright idea had
never come to pass. It has delayed the release by months. Oh well.
Still, could we use make(1) for *all* of the testing and not use `ls -t`
I guess it is technically possible, but I somehow feel doubtful about
relying entirely on make. Using ls already has plenty of portability
issues; I shudder to think how many strange problems we'll run into when
we start exercising timing edge cases in make.
Well, after having had some time to think about this, I have noticed a
logic error in the current code. When
_AM_FILESYSTEM_TIMESTAMP_RESOLUTION was introduced in commit
720a1153134b833de9298927a432b4ea266216fb, it did not use make. Commit
23e69f6e6d29b0f9aa5aa3aab2464b3cf38a59bf introduced the use of make in
that test to work around a limitation on MacOS, but using make(1) in
AM_SANITY_CHECK seems to be a logic error, since the user may want to
build with a different $MAKE, which may have different characteristics
from the system make.
I think that we actually need a new AM_PROG_MAKE_FILESYSTEM_TICK_DELAY
or similar that packages needing that information can use, and I think I
have a way to revise AM_SANITY_CHECK that can avoid any sleep in the
most common cases. There is no way to avoid sleeping when we need to
measure the exact delay needed for files to be distinguishably newer,
but most packages probably do not care about that, and (in the most
common case) we can expect configure's mtime to be backdated according
to the tarball it was unpacked from. If configure was recently
regenerated, we need only sleep 1 (classic POSIX) or 2 (FAT) seconds
before either passing the test or declaring the build environment
insane. However, a package with a large number of configure scripts
will only need for one of them to sleep; the rest will all then be old
enough to take the zero-delay path.
Are you willing to consider patches on this?
-- Jacob
