RFR: JDK-8210962 Deprecate jdk-variant

[Erik Joelsson]

On 2018-09-20 10:24, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-20 18:59, Aleksey Shipilev wrote:
>> On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote:
>>> A long time ago, we supported different "variants" of the JDK build, 
>>> like "normal" and "embedded".
>>> The --with-jdk-variant and associated machinery has been kept in 
>>> place, even though it's not doing
>>> anyting. Time to remove it.
>>>
>>> I chose to keep the "-normal-" in the build output name so as not to 
>>> break any scripts. But I'm
>>> willing to change this if someone has a clear opinion otherwise.
>> This breakage would happen at some point anyway, unless we accept 
>> that "-normal-" would linger
>> forever. It is probably for the best to break it when we purge the 
>> configure option.
I concur with Alexsey and say we remove it with the option. For me, 
removing this is the biggest improvement. :)
> I'm actually not very fond of the build output name format, and have 
> considered changing it drastically for some time. Maybe this should be 
> the time.
>
> Currently the default format looks like this: 
> "linux-x86_64-normal-server-release", that is 
> <OS>-<CPU>-<JDK_VARIANT>-<JVM_VARIANT>-<DEBUG_LEVEL>. The selection of 
> these configuration parameters feels a bit arbitrary. Some examples of 
> other parameters we could have included, but don't, are:  abi-profile, 
> jvm-features, version-string, static-build, headless-only.
>
> The relevance of including any of these parameters in the build output 
> name depends on some thought-up scenario were the alternative 
> configurations that reasonably could be built at the same time. For 
> instance, in a cross-compilation scenario, os and cpu makes sense to 
> include, but perhaps not otherwise. The jvm-variant is more or less 
> reduced to server or zero at this time, and it's unclear if this needs 
> to be part of the build output directory name.
>
> When building with the Oracle jib tool, we get profiles named like 
> "linux-x64" or "linux-x64-debug". To me, this is not such a mouthful 
> as the default configure name.
>
> Or perhaps we should have names that are more dynamic? Just like the 
> debug-level is either empty (for release) or "-debug" in the jib name, 
> maybe we should skip elements if they have a default value? So 
> linux-x86_64-zero would mean the JVM variant zero, but linux-x86_64 
> mean the JVM variant server (default)? And 
> linux-x86_64-zero-static_build-headless_only-fastdebug would be just 
> that...
>
A problem with empty default, which I often curse myself for in the case 
of the jib named output dirs, is that if you have both linux-x64 and 
linux-x64-debug, you can't easily pick linux-x64 with "make CONF=", you 
have to work around it by doing "make CONF_NAME=linux-x64", which is 
very annoying. I regret that naming convention for this reason.

On the other hand, we cannot have an arbitrarily large tuple all the 
time either.

I think that <OS>-<CPU>-<DEBUG_LEVEL> would be the most common base and 
that you could add additional parts for other parameters if they deviate 
from defaults, or perhaps if they are explicitly set, even if matching 
the default. Several of the parameters you mention above would be good 
candidates for conditionally changing the output dir.

/Erik