RFR: JDK-8282700: Properly handle several --without options during configure [v2]

[Magnus Ihse Bursie]

On Tue, 8 Mar 2022 02:48:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> ... and this goes for all the changes in the PR.
>
> I'm of the opinion that options which cannot have empty values, and will fall back to default ones if no explicit one is provided, would generate an error if --without-* is passed, while others that _can_ have empty values allow passing --without-* explicitly. From what I can gather so far, everything in branding.conf and a few other crucial options like --with-version-string or --with-version date are cases of the former, while --with-vendor-version-string would be an example of the latter. That said, it would be weird if we're folding no results into the yes branch, since passing --without-* would then return an error mentioning --with-* instead, which is in turn potentially confusing. Since we're on the topic, if this is the case, should -with-*= be considered as an error as well, for options that cannot have no value? (Currently it just assumes "Use the default value")

This entire PR feels like a non-issue. 

I agree that the UX of the --with-* flags are not optimal, but I also doubt it worth putting much time and effort into fixing. Going through each and every --with-flag to determine the best way to handle the (almost always incorrect) --without-* variant is not something I'd look forward to.

If anything should be done at all, I sincerely believe that merging "yes" and "no" will be the best way to handle. The fact that the error message mentions "--with" instead of "--without" is of no significance, since that's the way we treat the --with flags everywhere, just as the --enable/--disable dichotomy.

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

PR: https://git.openjdk.java.net/jdk/pull/7713