Re: [PATCH 5/5] configure.ac: upgrade to a compilation check for sysinfo

From

Ramsay Jones <ramsay@ramsayjones.plus.com>

Date

May 8, 2025, 23:01 UTC

Message-ID

<56706ad8-93c6-48cd-ad16-9d8b00a669c9@ramsayjones.plus.com>

In-Reply-To

<9baad29d-a5bf-443d-98a1-36d7020e5835@gentoo.org>

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.

> 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!