Here's the latest patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/
The changes are: - restructured the native libraries from one directory to several directories on a per DLL/EXE basis - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk - removed the source for the Ferret and Monkey test tools which will be the subject of a later patch - removed the DEF files; although they were used in the build, there are no build or runtime problems after their removal On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: > On 2015-03-23 18:31, Pete Brunet wrote: >> Hi Erik, >> >> I tried the restructuring about 2 weeks ago and the build failed trying >> to find an h file in the common directory. I used two directories on >> the SRC := setting for SetupNativeCompilation but the build failed not >> finding an h file located in the second (common) directory. > > For .h files, you need to also set the -I flag correctly. This is not > done automatically from SRC. (Maybe it should.) > > We have a pattern that you can copy to get this behavior. E.g. > > LIBINSTRUMENT_SRC := > $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ > $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument > \ > # > LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ > $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ > -Isomewhere-else \ > # > >> >>> There are a number of extra .cpp files in the libaccessbridge dir that >>> aren't used in any of the libraries. What is the purpose of those? >>> Keeping source code around that is not being built seems strange to >>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>> .DEF files used for anything? If all these files really need to be >>> included in our source base, perhaps sort them out into a >>> jdk.accessibility/windows/native/misc dir or something so that it's >>> clear what is needed to build the product and what is not? >> The Ferret and Monkey tools need to be built and added to the JDK >> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files plus >> AccessInfo.cpp. Do you want me to remove those now and add them back in >> later? > I would prefer that. It is generally better to make each change > coherent, unless there is much work in making some changes that will > very shortly be undone. This is not the case here. This change should > only add the files that are needed for these dll:s to compile. > >> >> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >> without it. >> >> WinAccessBridge.DEF seems like it might be needed. What do you think? > > Is it accessed by the compiler? Unless it is given as input to the > compiler or linker command line, it is not used in the build. Unless > the microsoft compiler does some magic trick and picks up files > unasked based on filename, that is. (Unlikely but not impossible, but > I'd like to see that proved.) > > /Magnus
