Re: use of make in AM_SANITY_CHECK (was: improved timestamp resolution test)

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