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. :)
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
