On 3/25/15 3:01 AM, Erik Joelsson wrote: > Hello Peter, > > The new source layout and Lib-jdk.accessibility.gmk look much better. > Thanks! > > Regarding the .def files, I was mistaken and missed that they were > referenced in the LDFLAGS, they were indeed used in the build so no > reason to remove them. Thanks Erik, My build and tests ran OK so apparently they are no longer needed.
To all: My hope is to push this patch into 9 tomorrow (Thursday) so please let me know if there are any additional issues as soon as you can. Pete > > /Erik > > On 2015-03-24 22:36, Pete Brunet wrote: >> 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 >