Re: [PATCH 1/6] meson: simplify and parameterize various standard function checks

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 22, 2025, 15:17 UTC
Message-ID: <xmqq4iyg5ip2.fsf@gitster.g>
In-Reply-To: <aAdFysi-n_5Aa4Au@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> Yeah, this is somewhat unfortunate indeed. I think in the long term we
> might want to unify our approach so that we consistently use e.g.
> `HAVE_SOME_FUNCTION` or `NO_SOME_FUNCTION`.

Yes and no, because the intention, at least in the original form, was that HAVE_FOO is not necessarily !NO_FOO. You cannot claim to HAVE_FOO on a system that does not have FOO, and expect the result to build and/or function, but you should be able to build with NO_FOO on a system that supports FOO and use an alternative implementation that does not rely on system-supplied FOO. NO_MMAP and NO_REGEX comes to mind (I often have to build NO_REGEX locally when doing "make sparse", for example, to avoid warnings triggering on system headers, for example).

I suspect that majority of these feature symbols do not fall into the same category as NO_REGEX, i.e. the user/builder may choose to decline using the system-supplied one. So for them this is a total overkill, but conceptually, building with feature FOO enabled should be done iff (HAVE_FOO && !NO_FOO).

I do not mind changing the stance Makefile takes on HAVE/!NO division, and see us declare that from now on, even when auto-detection flips HAVE_FOO on, the way for the builder to decline use of FOO is to flip HAVE_FOO off manually. I and others may need to tweak some scripts and figure out to pass !HAVE_REGEX instead of NO_REGEX when that happens, but that is a one-time cost to make things more consistent.