RFR: JDK-8210962 Deprecate jdk-variant

[Maurizio Cimadamore]

I have been bitten by this change - not something too difficult to 
handle, but I think it can be confusing - e.g. if you run 'make 
reconfigure' the old config name will be preserved, but if you run 'sh 
configure' from scratch you will have two configuration sitting beside 
each other and any make command w/o an explicit SPEC arg will fail.

It would be useful if configure, or make could generate a warning saying 
that one deprecated configuration has been found and suggest user to 
remove it.

My 0.02$

Maurizio


On 20/09/18 19:35, Aleksey Shipilev wrote:
> On 09/20/2018 07:24 PM, Magnus Ihse Bursie wrote:
>> 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.
> I guess the question is how much variability is there in day-to-day builds. As the guy who builds
> lots of different configurations, I see great simplicity in maintaining current static label that
> captures most of the usual variability. For example, my current scripts have:
>
>     build_dir_base = 'build/' + os + '-' + target_oj + '-normal-' + variant + '-' + mode + '/'
>
> The only oddity here is "normal", which I would be happy to see going, even if this requires me to
> special case jdk-12+ build configs.
>
> Granted, scripts could be changed to accept whatever configuration label we come up with. I do not
> see any benefit of including the version-string (the really dynamic parameter?), that would justify
> additional work in build scripts. jvm-features-wise, I think most builders stick with the static set
> of features anyway. Headless/headful might be interesting, but I guess most builders do not care
> about headless anyway. ABI is interesting, but different-ABI-ed builds are is probably built in
> separate containers/machines anyway.
>
> -Aleksey
>
>
>
>