On Wed, 9 Mar 2022 04:36:13 GMT, Julian Waters <jwat...@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
