<AWT Dev> RfR JDK-8055831 Open Source Java Access Bridge

[Pete Brunet]

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
>