[cmake-developers] UseSWIG and enable_language(Java)

[Alan W. Irwin]

On 2017-08-01 16:29-0400 Brad King wrote:

> On 07/26/2017 06:02 AM, Alan W. Irwin wrote:
>
[...]
>> 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit
>>    UseSWIG: Record generated java files as custom command outputs
>
> Hmm.  That causes swig_add_library's call to add_library to include
> the generated .java source file as a source (since it is the
> output of a custom command we want to run).
>
> However, with `enable_language(Java)` CMake thinks it is supposed
> to compile the .java file as part of the (module) library.  That's
> why it looks for CMAKE_Java_CREATE_SHARED_MODULE.
>
> Please try the patch below.
>
>
> diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
> index 456a6bd63d..48d6a5b4af 100644
> --- a/Modules/UseSWIG.cmake
> +++ b/Modules/UseSWIG.cmake
> @@ -121,8 +121,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile)
>
>   endif()
>   foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS})
> -    set(${outfiles} ${${outfiles}}
> -      "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
> +    set(extra_file "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
> +    list(APPEND ${outfiles} ${extra_file})
> +    set_property(SOURCE "${extra_file}" PROPERTY LANGUAGE "")
>   endforeach()
> endmacro()

Hi Brad:

Thanks for your response.

Yes, that patch works for PLplot.  In particular, our multiple sets of
~30 standard examples written in Python, Java, and ~10 other languages
produce the same PostScript plot files as the corresponding set of
standard examples written in C.  So that is a pretty good test.

Furthermore, if I am understanding its logic correctly this patch
empties the LANGUAGE property for these extra Java and Python files to
force these files NOT to be compiled (which would make no sense in any
case because swig-generated bindings are implemented as C or C++
modules). That forcing is actually not needed in the Python case
because Python is a scripting language, but that forcing is needed for
Java precisely because that language can be compiled.  So my
understanding of the purpose of this patch is consistent with my
experience (our Python binding works regardless of whether this patch
is applied or not and our Java binding only works when the patch is
applied).  However, if I got something wrong in this explanation of
the patch, please correct!

Assuming you are going to commit this patch is it something that
needs further extensive testing or will it go into one of the
CMake-3.9.x releases?

Second related topic:

[out of order]
>> enable_language(Java)
>
> FWIW this language support is quite limited, is not well tested,
> and has long been superseded by `UseJava.cmake`.  I suggest porting
> away from it in PLplot.

Let me give you some additional PLplot use case background information
before commenting on your suggestion.

I haven't been paying much attention to the java-related part of our
build system since it was almost entirely implemented a decade ago and
normally it has "just worked" during that time.  But a quick review of
it now indicates it is quite primitive (probably because of the
limited CMake Java support a decade ago). It uses
${CMAKE_Java_COMPILER} (which is set to /usr/bin/javac for my current
system) in a custom command to compile *.java files into *.class files
for both our Java binding and Java examples.  Collecting all those
binding and examples *.class results into a jar file using
${CMAKE_Java_ARCHIVE} (which is set to /usr/bin/jar for my current
system) is an afterthought.

Apparently, both CMAKE_Java_COMPILER and CMAKE_Java_ARCHIVE are determined
when our build system executes "enable_language(Java)".  So that
command is required at the moment.  But I think we are only using its
find capabilities so we could simply drop using it and
substitute instead the appropriate find commands to find the needed
javac and jar directly or call find_package(Java) to do the same.
So that is likely what I will implement in the short term to
avoid any other issues with the poorly supported
"enable_language(Java)" command.

It also appears from the UseJava.cmake documentation, that that module
allows us to build our jar file directly, thus allowing replacement of
all those primitive custom commands.  But making that change appears
to be quite a bit of work, and there is no urgency for switching since
we have the above alternative. But if the required CMake code is truly
at lot higher level and therefore more compact, then we should
consider trying this suggestion in the long term, although see below.

Different, but related third topic:

PLplot developers might want to implement an option to use gcj
directly without the -C option (rather than its javac wrapper which
always uses the gcj -C option) to compile our *.java files into
ordinary machine object code that is stored in an ordinary library. Of
course, modifying our present primitive approach to do that should be
entirely straightforward.  But it appears UseJava.cmake does not
support such machine code capability which is a possible strike
against that approach from our perspective.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________