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

[Julian Waters]

On Mon, 7 Mar 2022 19:54:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think this, even more, makes it clear that `--without-vendor-url` can´t possible be meant to be interpreted as "use https://openjdk.java.net/". 
>> 
>> Basically, I think what I'm arguing for is that we can fold this check into the "yes" check -- both `--with-vendor-url` (with no given value) and `--without-vendor-url` are invalid. So something like this:
>> 
>> 
>>  if test "x$with_vendor_url" = xyes || test "x$with_vendor_url" = xno; then
>>     AC_MSG_ERROR([--with-vendor-url must have a value])
>>   elif...
>
> ... 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")

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

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