RFR: JDK-8210962 Deprecate jdk-variant

[Magnus Ihse Bursie]

On 2018-09-20 19:47, Erik Joelsson wrote:
> 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. :)

Ok, I hear you. :-)

Here is an updated webrev, where I remove the "-normal-" part of the 
build output name.

http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.02

Let's discuss any further changes to the build output name separately. 
I'll see if I can whip up some prototype and then we can prod it around 
a bit until we are all satisfied.

/Magnus


>> 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