On Mon, Nov 18, 2024 at 09:48:06PM +0900, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > Now there will be exceptions where it does make sense to make something > > a build option, due to whatever reason. But I'm in the camp of adding > > them as-needed and not proactively so that we don't end up with hundreds > > of options. > > Surely, your system may have openssl installed, but for > non-technical reasons you may not want your Git to link with it, > which is impossible to auto-detect, of course. > > To be quite honest, while I am very much sympathetic to the above, > in practice, I am afraid that these knobs we _already_ have in our > Makefile are exceptions that was added due to whatever reason "as > needed". Dropping any of them would mean that you are declaring > this: by default, all the past exceptions we made are nullified and > you have to resubmit for requalification if you want to keep your > favourite one. > > That's not a very nice way to run the project, though. There is a difference though: you are talking about actual features wired into Git, whereas I'm talking about other things like "Does the system have `uintmax_t`?". The former is a strong must to be toggled by the user, and it is already wired up like this: you can choose to compile without OpenSSL and any other optional library with Meson. All toggles we have in this context in our Makefile must be supported by Meson. While auto-detection is nice to have, it is mandatory that the detection can be disabled. 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. Patrick
