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

[Julian Waters]

On Tue, 8 Mar 2022 14:02:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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.

I disagree with the assessment that this isn't an issue, since as I mentioned above this can be fairly confusing, but I do concede that it would be tedious to check every flag like this, so it seems merging yes and no is the way to go. In that case though, I'm wondering if we should fold the x$with_foo = x (ie --with-foo= ) into the yes and no check as well, since right now if that's passed it assumes that the default option is requested. I could also change the error message to be a generic one that matches both conditions, but I'll leave that up for discussion for the time being

As a side note, I'm also willing to be responsible for properly checking every --without variant of all the current flags and any future ones, if it ever comes to that

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

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