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

[Magnus Ihse Bursie]

On Wed, 9 Mar 2022 04:36:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

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

Don't change the check for empty values.

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

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