RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834

[Magnus Ihse Bursie]

Looks good to me. 

I agree with Erik that a comment describing the fix for the find/delete issue would be good. Are other uses of FIND_DELETE problematic on AIX as well?

I wholeheartedly support all continued cleaning up of native files, and have suggested this fix already. Erik has probably put it in one of the cleanup bugs he created with my Jigsaw code review comments. 

/Magnus

28 aug 2014 kl. 17:22 skrev Volker Simonis <volker.simonis at gmail.com>:

> Hi,
> 
> could somebody please review the following small changes to fix the
> AIX build after the Modular Source Code change 8054834. I've also done
> a little cleanup which is detailed below:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/8056246/
> https://bugs.openjdk.java.net/browse/JDK-8056246
> 
> make/lib/Awt2dLibraries.gmk
> 
> LIBAWT_CFLAGS contains quite some duplicate include parameters which
> can be removed.
> 
> -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt
> isn't required because the path
> $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/common/sun/awt
> is already part of LIBAWT_DIRS and the corresponding include parameter
> is already generated by $(addprefix -I, $(shell find $(LIBAWT_DIRS)
> -type d))
> $(foreach dir, $(LIBAWT_DIRS), -I$(dir)) isn't required either,
> because $(addprefix -I, $(shell find $(LIBAWT_DIRS) -type d)) not only
> creates include parameters for every sub-directory contained in
> LIBAWT_DIRS, but also for the directories themselves.
> 
> make/rmic/Rmic-java.management.gmk
> 
> This change is a little bit hacky, but it's the best I could find for
> the moment. The problem is that find on AIX (but also GNU find before
> version 4.2) are buggy in the sense that they will report an error if
> "-exec \+" is used in cases where the find command won't find any
> files.
> 
> Therefore, the following make rule will fail for incremental builds if
> the $(RMIC_GENSRC_DIR) directory won't contain any *.class files any
> more. These class files are deleted during the first invocation of the
> rule. However, the rule will be re-executed for every new build
> because its target depends on the deleted files.
> 
> $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC)
>       $(FIND) $(RMIC_GENSRC_DIR) -name "*.class" $(FIND_DELETE)
>       $(TOUCH) $@
> 
> I've therefore added the file _the.classes.removed to the find
> pattern. That way, the find command will always match at least one
> file and the buggy "-exec \+" won't complain.
> 
> $(RMIC_GENSRC_DIR)/_the.classes.removed: $(RMI_IIOP) $(RMI_SRC)
>       $(FIND) $(RMIC_GENSRC_DIR) \( -name "*.class" -o -name $(@F) \)
> $(FIND_DELETE)
>       $(TOUCH) $@
> 
> Notice, that deleting _the.classes.removed is no problem here, because
> the the file will be recreated by the following touch command.
> 
> I've build and smoke tested these changes on Linux/x86_64,
> Linux/ppc64, MacOS X, Solaris10/SPARC and AIX.
> 
> Thank you and best regards,
> Volker
> 
> PS: I would also like to do some further cleanup in
> NetworkingLibraries.gmk in a follow-up change. I think now that we
> have all the corresponding directories in place we could rename
> {solaris,linux,bsd}_close.c to just close.c and move them to
> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/native/libnet. We
> could than get rid of the platform dependent  LIBNET_EXCLUDE_FILES in
> NetworkingLibraries.gmk. What's your opinion?