I presented the test results:
> - hello-3: no gnulib, just AC_SYS_LARGEFILE_REQUIRED
> - hello-4: no gnulib, just AC_SYS_YEAR2038_REQUIRED
> - testdir3: a gnulib testdir for the modules largefile-required stat
> - testdir4: a gnulib testdir for the modules year2038-required stat
>
> mingw64 mingw32 msvc64 msvc32
>
> hello-3 OK OK "support not detected" -> fail
> hello-4 OK OK "support not detected" -> fail
> testdir3 OK OK OK OK
> testdir4 OK OK OK OK
Now, one could argue that in the above table the outcome should be:
mingw64 mingw32 msvc64 msvc32
hello-3 OK OK "support not detected" -> fail
hello-4 OK OK OK OK
testdir3 OK OK OK OK
testdir4 OK OK OK OK
since in hello-4 the maintainer has only asked for year 2038
support, not for large files support. And the dependency from year 2038
support to large files support exists only in glibc (since the glibc
developers found it pointless to add a 'struct stat' variant with
32-bit off_t and 64-bit time_t). Whereas MSVC has all 4 possible
variants for 'struct stat' (32/64-bit off_t and 32/64-bit time_t) [1].
But for this improvement, the Autoconf code of AC_SYS_YEAR2038_REQUIRED
would need to distinguish glibc systems from MSVC systems in one way or
the other. You said that you don't like the use AC_CANONICAL_HOST here;
on the other hand, an extra compiler or preprocessor invocation is
pointless if AC_CANONICAL_HOST has already been used.
Anyway, this is low priority for me, since MSVC support without gnulib
is not going to work well in so many aspects anyway.
Bruno
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170
