Not exactly sure what you mean with the duplication other than the
comment in the last rule being wrong. One rule is for copying from
jdk/lib and the other from images/lib. Both sources contain files that
are going into the image.
/Erik
On 2012-10-09 04:10, David Holmes wrote:
Hi Erik,
In Images.gmk you seem to have duplicated the targets/instructions for
copying rather than updating them ie:
197 $(JRE_IMAGE_DIR)/lib/%: $(JDK_OUTPUTDIR)/lib/%
198 $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@)
199 $(install-file)
200
...
222 # Rules for copying from images/jar directory
223 $(JRE_IMAGE_DIR)/lib/%: $(IMAGES_OUTPUTDIR)/lib/%
224 $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@)
225 $(install-file)
Otherwise I've looked through and fwiw have "Reviewed" the changes.
The proof as always is in the building.
A couple of to-do items for future cleanup:
- remove hardcoded build number and milestone from version.numbers
- relocate closed.version.numbers to the closed repo and access it by
checking for $(CUSTOM_MAKE_DIR)/version.numbers
- remove hardwiring of src/closed paths for socketOptions etc
BTW I still haven't seen a resolution to my problem trying to build on
Solaris. I'll re-try with latest build-infra.
Cheers,
David
-----
On 9/10/2012 1:09 AM, Erik Joelsson wrote:
After achieving the milestone of equivalent images from the new and old
build, this is a good time to refresh build-infra in jdk8. Here is a
webrev with the proposed changes:
http://cr.openjdk.java.net/~erikj/build-infra5/webrev.01/
<http://cr.openjdk.java.net/%7Eerikj/build-infra5/webrev.01/>
Unfortunately the builds will not be as equal in jdk8 as in the
build-infra forest due to bug "JDK-8000518 - Javac generates duplicate
name_and_type constant pool entry for class BinaryOpValueExp.java".
Running the comparison script also takes a very long time because of it.
/Erik
