On 9/10/2012 6:06 PM, Erik Joelsson wrote:
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.
I thought you were only allowed to define one recipe per target? Or are
we going to find disjoint sets of files in each location?
These wildcard based targets and dependencies still cause me some
confusion. I don't understand what process make follows to actually
determine what the real set of targets is.
David
/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
