Bug 946083 - Part 1: Delete .class files when (re-)building a Java JAR. r=glandium, a=sylvestre
authorNick Alexander <nalexander@mozilla.com>
Tue, 11 Feb 2014 09:55:47 -0800
changeset 177121 81965a501118db3f9bb7c099597fed00b985f4c5
parent 177120 69da855f60a7d1b0948cb56c8522ccb527828575
child 177122 d37272b4e6c8d5a868ea96a245faa463c3e4efbb
push id5263
push usernalexander@mozilla.com
push dateWed, 19 Feb 2014 16:56:26 +0000
treeherdermozilla-aurora@d37272b4e6c8 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersglandium, sylvestre
Bug 946083 - Part 1: Delete .class files when (re-)building a Java JAR. r=glandium, a=sylvestre This cleans up stale .class files, so they don't get packaged into the .jar files that Proguard consumes.
--- a/config/makefiles/java-build.mk
+++ b/config/makefiles/java-build.mk
@@ -78,19 +78,27 @@ endif #} ANDROID_APK_NAME
 # Arg 1: Output target name with .jar suffix, like jars/jarfile.jar.
 #        Intermediate class files are generated in jars/jarfile-classes.
 # Arg 2: Java sources list.  We use VPATH and $^ so sources can be
 #        relative to $(srcdir) or $(CURDIR).
 # Arg 3: List of extra jars to link against.  We do not use VPATH so
 #        jars must be relative to $(CURDIR).
 # Arg 4: Additional JAVAC_FLAGS.
+# Note: Proguard fails when stale .class files corresponding to
+# removed inner classes are present in the object directory.  These
+# stale class files get packaged into the .jar file, which then gets
+# processed by Proguard.  To work around this, we always delete any
+# existing jarfile-classes directory and start fresh.
 define java_jar_template
 $(1): $(2) $(3)
+	@$$(RM) -rf $(1:.jar=)-classes
 	@$$(NSINSTALL) -D $(1:.jar=)-classes
 	@$$(if $$(filter-out .,$$(@D)),$$(NSINSTALL) -D $$(@D))
 		-d $(1:.jar=)-classes\
 		$(if $(strip $(3)),-classpath $(subst $(NULL) ,:,$(strip $(3))))\
 		$$(filter %.java,$$^)
 	$$(JAR) cMf $$@ -C $(1:.jar=)-classes .