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
