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

[Junio C Hamano <gitster@pobox.com>]

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.