Re: [-SPAM-] [PATCH RFC v7 00/22] Modernize the build system

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2024, 23:39 UTC
Message-ID: <xmqq7c90jen3.fsf@gitster.g>
In-Reply-To: <Zzs7gerRLH0WlM-j@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 8 quoted lines

> But for the second group I'm sceptical whether these really should be
> configurable by the developer. Why would you care whether you use
> `uintmax_t` provided by the system or by Git as a compat macro? I don't
> see a strong reason to let the developer override this in a build system
> that knows to auto-detect the availability of such features.
>
> Now as said, there may be cases where it indeed is useful, but in
> general I don't think it is.

I think we are on the same page, then. When you said "detect", my primarily thought was "uintmax_t and the presense of OpenSSL are both auto-detectable, but the latter is a choice---forcing folks to fight again to support the choice is unnice", while auto-detection of the former in my mind was a given (perhaps think of "make + autoconf" in an ideal world as a baseline for comparison).

There may be cases where it may be handy to pretend that types and library functions your system offers do _not_ exist, for various purposes like test-building or performance tuning, but these purposes are of lessor importance than exclusion by policy, I would say.