On 08/05/2025 22:07, Eli Schwartz wrote:
> On 5/8/25 12:44 PM, Ramsay Jones wrote:
[snip]
>> In order to correctly identify the 'sysinfo()' function we require as
>> part of 'git-gc' (used in the 'total_ram() function), we also upgrade
>> to a compilation check, in a similar way to the meson commit. Note that
>> since commit c9a51775a3 ("builtin/gc.c: correct RAM calculation when
>> using sysinfo", 2025-04-17) both the 'totalram' and 'mem_unit' fields
>> of the 'struct sysinfo' are used, so the new check includes both of
>> those fields in the compile check.
>
> and
>
>> Note that I cannot test the new autoconf check in patch #5 (I don't have
>> access to a Solaris system). I _think_ it will correctly unset HAVE_SYSINFO
>> on Solaris, but I cannot confirm that. (I can only test on Linux and cygwin).
>
>
> Well, I can confirm this results in the detection being correctly
> changed on Solaris 11.3 and stop reporting sysinfo as available during
> ./configure, so this has my ACK on technical grounds.
Thank you very much for testing this patch, much appreciated!
[snip]
>
> So you are indeed teaching autoconf to check for this function, but
> should we also ask whether it's worth continued maintenance of autoconf?
> It was/is not clear to me who the stakeholders are for the autoconf support.
Hmm, someone posted a list of people using autoconf somewhat recently
to the mailing-list ... I don't have it to hand, but cygwin was one
of the projects using it.
> On the one hand, it exists so maybe it should be fixed when we know it
> has issues.
Yes, exactly.
> On the other hand, it sounds like this patch (and commit 50dec7c566
> "config.mak.uname: add sysinfo() configuration for cygwin") only modify
> autoconf out of a sense of duty, rather than finding autoconf useful.
Hmm, I am not convinced (yet) that meson is all that useful either. ;)
> What does it say about the autoconf support if the people finding bugs
> in it don't even use it, but only discovered the bug while working on a
> different build system they do use and depend on (config.mak.uname, or
> meson.build, both count here).
I am trying very hard not to express a view on this debate. :)
[well, except that I find CMake to be absolutely awful!]
Thanks!
ATB,
Ramsay Jones
