On Fri, 22 Nov 2024 13:56:32 GMT, Erik Joelsson <er...@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
