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

[Magnus Ihse Bursie]

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