<AWT Dev> RfR JDK-8055831 Open Source Java Access Bridge
peter.brunet at oracle.com
Tue Mar 24 21:36:54 UTC 2015
Here's the latest patch:
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 \
> 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
> 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.)
More information about the awt-dev