RFR: JDK-8210962 Deprecate jdk-variant

[Erik Joelsson]

Looks good.

/Erik


On 2018-09-20 11:42, Magnus Ihse Bursie wrote:
>
>
> 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
>