On Tue, 26 Nov 2024 18:08:24 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> 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. I disagree on the concept of `--without-<foo>` not being a valid usecase. It's very useful to be able to do for example `--without-devkit` to override a previous `--with-devkit=...` on the command line, when you are not in control of the full command line yourself. The typical usecase for me is when configuring using jib to get the Oracle official configuration, but wanting to override something specific. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22231#discussion_r1865998542
