Hi Erik, This is great news! The dollar escaping stuff was a nightmare.
Thanks, David On 3/06/2014 12:09 AM, Erik Joelsson wrote:
Hello Emmanuel, I remember that piece of make logic being especially tricky to get working and it seems the weirdness in make has been fixed in make 4.0, or at least changed. Our dealing with escaping dollars is rather messy in JDK 8. I have recently worked on this in a JDK 9 project, where I have chosen a different approach that seems to work with both 3.8x and 4.0. The idea is based on defining this macro in make/common/MakeBase.gmk: ################################################################################ # This macro translates $ into \$ to protect the $ from expansion in the shell. # To make this macro resilient against already escaped strings, first remove # any present escapes before escaping so that no double escapes are added. EscapeDollar = $(subst $$,\$$,$(subst \$$,$$,$(strip $1))) And then instead of escaping dollars explicitly in make variable declarations, just call that macro before giving anything containing dollars to the shell. --- a/make/CreateJars.gmk +++ b/make/CreateJars.gmk @@ -302,17 +302,15 @@ # methods from classes that only go into the profile builds. BEANLESS_CLASSES = $(IMAGES_OUTPUTDIR)/beanless -# When there are $ characters in filenames we have some very subtle interactions between -# make expansion and shell expansion. In this particular case $< will contain a single $ while -# $@ will contain \$. So we have to pass $< in single-quotes to avoid shell expansion $(BEANLESS_CLASSES)/%: $(JDK_OUTPUTDIR)/classes/% $(MKDIR) -p $(@D) - $(TOOL_REMOVEMETHODS) '$<' $@ addPropertyChangeListener removePropertyChangeListener + $(TOOL_REMOVEMETHODS) $(call EscapeDollar, $<) $(call EscapeDollar, $@) \ + addPropertyChangeListener removePropertyChangeListener CLASSES_TO_DEBEAN = \ java/util/logging/LogManager.class \ - java/util/jar/Pack200\$$Packer.class \ - java/util/jar/Pack200\$$Unpacker.class \ + java/util/jar/Pack200$$Packer.class \ + java/util/jar/Pack200$$Unpacker.class \ com/sun/java/util/jar/pack/PackerImpl.class \ com/sun/java/util/jar/pack/UnpackerImpl.class @@ -345,7 +343,7 @@ $(CD) $(patsubst %$(VERSION_CLASS_PATH), %, $(CLASS_FILE)) && \ $(JAR) $(RT_JAR_UPDATE_OPTIONS) [email protected] $(VERSION_CLASS_PATH); \ $(CD) $(BEANLESS_CLASSES) && \ - $(JAR) $(RT_JAR_UPDATE_OPTIONS) [email protected] $(CLASSES_TO_DEBEAN); \ + $(JAR) $(RT_JAR_UPDATE_OPTIONS) [email protected] $(call EscapeDollar, $(CLASSES_TO_DEBEAN)); \ fi $(MV) [email protected] $@ The patch above works for me at least. /Erik On 2014-05-31 15:35, Emmanuel Bourg wrote:Hi, I'd like to report an issue with the build for the OpenJDK 8 compact profiles. On Debian the build fails when PropertyChangeListener is removed from the pack200 classes: ## Starting profiles /usr/bin/find: `/home/ebourg/jdk8u-dev/build/images/lib': No such file or directory make[2]: *** No rule to make target '/home/ebourg/jdk8u-dev/build/images/beanless/java/util/jar/Pack200\$Packer.class', needed by '/home/ebourg/jdk8u-dev/build/images/libprofile_1/rt.jar'. Stop. make[2]: *** Waiting for unfinished jobs.... Removed method addPropertyChangeListener(java.beans.PropertyChangeListener) from java/util/logging/LogManager Removed method removePropertyChangeListener(java.beans.PropertyChangeListener) from java/util/logging/LogManager BuildJdk.gmk:113: recipe for target 'profile_1' failed make[1]: *** [profile_1] Error 2 /home/ebourg/jdk8u-dev//make/Main.gmk:147: recipe for target 'profiles-only' failed make: *** [profiles-only] Error 2 The same issue was reported last year on Arch Linux: http://mail.openjdk.java.net/pipermail/build-dev/2013-July/009557.html It looks like this error is caused by GNU Make 4.0 which is now the default in Debian. I was able to build the compact profiles after downgrading make to the version 3.81. OpenJDK 9 isn't affected by this issue because the add/removePropertyChangeListener() methods are already removed. Make 4.0 caused another regression (JDK-8028407) which has been fixed for OpenJDK 9. Could you also consider backporting it to OpenJDK 8 please? Thank you, Emmanuel Bourg
