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
