Hello
New webrev: http://cr.openjdk.java.net/~erikj/8170741/webrev.02/
On 2016-12-08 14:19, Magnus Ihse Bursie wrote:
On 2016-12-05 16:35, Erik Joelsson wrote:
For a while now, Oracle engineers have been able to configure builds
of JDK 9 with binary dependencies automatically downloaded from an
artifact storage, using Jib. Since then, Jib has been enhanced to
also support publishing build artifacts produced by the build into
the same storage. Such artifacts can subsequently be used as
dependencies for other build targets.
With this change, the Jib profiles configuration in JDK 9 are updated
to leverage this new functionality in Jib. By doing this, we are able
to express and define all deliverables from the build in the source
code. We are also able to define possible workflows where one build
step requires input from another.
This change attempts to describe all artifacts currently built and
stored by RE, with a few known exceptions that will be adjusted in
followup fixes.
With this change, there is a fair bit of refactoring in the
jib-profiles.js file(s). The old designe resulted in a fair bit of
duplicated configure arguments and it was hard to control what
settings got duplicated in variants of profiles, such as *-debug. I
believe the new patterns are more flexible without sacrificing
readability. I have manually inspected the generated configure lines
for all relevant profiles and compared before and after the change to
make sure no regressions are introduced by this.
I moved more of the default version numbers into the version-numbers
file so that they can be read from jib-profiles.js.
In langtools/test/Makefile, I made it possible to override the
TEST_OUTPUT_DIR, like it is currently possible for the other test
makefiles.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170741
Webrev: http://cr.openjdk.java.net/~erikj/8170741/webrev.01/
Looks good to me overall, but I do not like the massive amount of code
duplication in profilesArtifacts. These could, and should, be
generated from some suitable input (like name of os and cpu in the
resulting bundle, etc)
Fixed.
The new print-config.js tool, is it used somewhere, or is it just
provided as a development tool for adhoc use? Is common/conf really
the proper place for it, and not common/bin?
Good point, moved.
/Erik
