bug#68808: subsecond mtime discovery code insufficient

2024-06-01 Thread Karl Berry
Do color-tests2.sh and color-tests2-w.sh both write to the same directory and, thus, running in parallel may have caused them to be writing to the same file(s) at the same time? Every test runs in its own t/*.dir/ directory. The ct2-w.sh test sources the ct2.sh shell script, but it's

bug#68808: subsecond mtime discovery code insufficient

2024-05-30 Thread Erik A Johnson
Hi, Karl. As you suspected, this was an issue of making in parallel. This was with the old make 3.81: my MAKEFLAGS is set to "-k -j12"; unsetting MAKEFLAGS and running works fine, with all tests passing. Do color-tests2.sh and color-tests2-w.sh both write to the same directory and, thus, runn

bug#68808: subsecond mtime discovery code insufficient

2024-05-29 Thread Karl Berry
Hi Erik, * color-tests2.sh and color-tests2-w.sh fail -- logs attached. Is this with the old make 3.81 from the system, or the new make you compiled? What is in the "stdout" file in t/color-tests2.dir/stdout? And, are these the only two tests that fail in the entire suite? What I see in the

bug#68808: subsecond mtime discovery code insufficient

2024-05-27 Thread Karl Berry
* fine on the tests that failed previously because of macOS default make having only second resolution Great! Thanks much for the instant testing. * color-tests2.sh and color-tests2-w.sh fail -- logs attached. I had tweaked some of the color stuff, so I must have messed up somewher

bug#68808: subsecond mtime discovery code insufficient

2024-05-27 Thread Erik A Johnson
Thanks, Karl. I wasn't sure what version was to be patched but it looks like the current git repository has those changes, so I tested that with the macOS make: * fine on the tests that failed previously because of macOS default make having only second resolution * color-tests2.sh and color-tes

bug#68808: subsecond mtime discovery code insufficient

2024-05-27 Thread Karl Berry
Hi Erik and all - I (finally) made the change below to have automake test for a make that doesn't support subsecond mtimes even when the rest of the system is ok, as you noted happens with the make-3.81 shipped by macOS. I installed make-3.8.1 on my Rocky 9 system, but it did not cause the lossage

bug#68808: subsecond mtime discovery code insufficient

2024-01-31 Thread Karl Berry
Those square brackets are M4 quotes to prevent M4 from expanding $* and $2 itself. Ah, right. Of course. Good! The $[*] especially confused me. Just looks so perfectly like an array reference of some strange kind :). I think it would be a tiny bit clearer to use $[]*? Or am I missing some

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Zack Weinberg
On Tue, Jan 30, 2024, at 6:32 PM, Karl Berry wrote: > test "$[*]" != "X conftest.ts1 conftest.ts2" || > .. > test "$[]2" = conftest.ts3 && > .. > etc. > > I've never seen anything like that before. Oh! Those square brackets are M4 quotes to prevent M4 from expanding $* and $2 itself. zw

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Karl Berry
(Off-topic for the original bug, but for the sake of public discussion ...) Hi Zack, It is absolutely not *supposed* to be using shell arrays. I guess it's not an array. It's the square bracket syntax that confuses me. A couple of examples from the fn in sanity.m4: test "$[*]" != "X confte

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Peter Johansson
On 30/1/24 22:46, Erik A Johnson wrote: (Why, then, does Apple continue to include 3.81 in the software 18 years later? Beyond me.) Probably because 3.81 was the last version released under GPLv2 or later and IIRC Apple avoids shipping things that are licensed with GPLv3. Cheers, Peter

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Zack Weinberg
On Tue, Jan 30, 2024, at 7:46 AM, Erik A Johnson wrote: > I found the problem! The default GNU make on macOS (even Sonoma) is > 3.81 from 2006! The configure script for GNU make versions <4.0 did > not have the right test for subsecond resolution in the macOS stat() > function, so 3.81 was built

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Erik A Johnson
I'm guessing the Mac (and its sleep command?) do support subsecond mtimes in reality. echo a > 1 && echo b > 2 && echo c > 3 && ls -t [123] consistently gives me the correct order (3 2 1). The macOS version of stat has a mtime_nsec field that is fully populated and the file modification

bug#68808: subsecond mtime discovery code insufficient

2024-01-30 Thread Erik A Johnson
I found the problem! The default GNU make on macOS (even Sonoma) is 3.81 from 2006! The configure script for GNU make versions <4.0 did not have the right test for subsecond resolution in the macOS stat() function, so 3.81 was built with resolution only to the second, not subsecond, thus needi

bug#68808: subsecond mtime discovery code insufficient

2024-01-29 Thread Zack Weinberg
On Mon, Jan 29, 2024, at 6:00 PM, Karl Berry wrote: > But, looking at that code, I belatedly see that shell arrays are being > used. At least I think so. It is absolutely not *supposed* to be using shell arrays. If it is, that was a mistake on my part. zw

bug#68808: subsecond mtime discovery code insufficient

2024-01-29 Thread Karl Berry
Hi Erik - following up on your final comment in #68119: P.P.S. It still needs export am_cv_sleep_fractional_seconds=false to correctly run the tests on macOS. Without that, 75-90 tests fail. Maybe we can try to figure out why the code that tries to automatically discern wheth