RFR: 8344318: Enhance configure help for enabling/disabling single JVM features

[Magnus Ihse Bursie]

On Fri, 22 Nov 2024 13:56:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We could maybe move the info to the start of the 'Optional Features:' section if you prefer this. Would be more general.
>> But is it really true that for all optional features the enable/disable syntax works ?
>
> For any `--enable-<foo>` flag autoconf generates a corresponding `--disable-<foo>` flag. Using `--enable-<foo>` is equivalent to `--enable-<foo>=yes` and using `--disable-<foo>` is equivalent to `--enable-<foo>=no`. It's encouraged (from autoconf) to have "enable/disable" flags only take those values, but technically, you could supply any value to them. 
> 
> We try to use `--with-<foo>` for parameters that expect different arguments and those are usually possible to turn off as well using `--without-<foo>`, which is equivalent to `--with-<foo>=no`. I don't think we have properly implemented support for every `--without-<foo>` in our configure script however.

Most --with flags actually check that we do *not* send in `no`; and those that don't probably should. :-) I can only think of a single case where we allow `--with-*=no`, and that is for gtest, where the way you disable it is to do `--without-gtest`.

Otherwise we really try to keep to the rule that `--enable/disable` are booleans that can be turned on or off, and `--with` are ways to send in an argument. But internally in autoconf, they are treated the same. And in GNU software, people do stuff like `--with-zlib` not to point to a library, but to enable linking with zlib, etc. So it's pretty messed up. I hope we can eventually ditch autoconf completely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22231#discussion_r1859028868