On Tue, 8 Mar 2022 02:48:45 GMT, Julian Waters <jwat...@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
