On Tue, 8 Mar 2022 14:02:35 GMT, Magnus Ihse Bursie <i...@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
