Patrick Steinhardt <ps@xxxxxx> 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.
