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
