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

[Magnus Ihse Bursie]

On 2015-03-25 15:44, Pete Brunet wrote:
>
> 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.
New version looks good to me too.

/Magnus

>
> 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