Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

[Alan W. Irwin]

Here is a spin-off topic from this thread which I believe may
be of general interest.

Bill Hoffman contacted me off list about the possibility of testing
cmake with a build of a rapidly changing CMake corresponding to the
tip of your release branch or possibly one of your development
branches AND a corresponding build of a slowly changing PLplot (say
change it once per release of PLplot) for each such CMake version.

That is a good idea because the PLplot build is fast.  For example,
the build of the "all" target (including all our standard examples for
our supported compiled languages) was completed in only 1 minute 40
seconds (with the aid of ccache) in a recent "make all" test.  Even
more importantly despite this quick build, the CMake-based build
system for PLplot (which we have been developing for the last decade)
is quite complex. That is, that build system has to find many soft
dependencies of PLplot (almost entirely generated by our various
optional device drivers), configure the build of our ~5 libraries,
configure the build of the PLplot bindings for our ~10 supported
computer languages, configure the build of ~30 standard examples
written in each of our supported computer languages for the subset of
those languages which are compiled, configure the build for ~15 PLplot
device drivers (typically configured as shared objects or DLL's that
are dynamically loaded by the core PLplot library if/when needed but
another configuration is also possible where the device code is
compiled directly into our core library), and configure many separate
test targets as well as ctest examples.

Because of these excellent PLplot project characteristics for CMake
testing purposes, Alex Neundorf set up a combined CMake build and
PLplot build test nearly a decade ago, but I assume that no longer
exists (although I have asked Bill to search for it, and maybe Alex
can comment as well on that CMake history back near the time when the
earth was still cooling.  :-) ). In any case, the ctest and dashboard
server facilities we have now are much better than they were a decade
ago, and I am consulting with Bill about the best way to use those
facilities properly to set up a new version of Alex's test.

And when that nightly test (currently in the very early planning
stages) consisting of a CMake build + PLplot build goes live, I think
it will be a noticeable improvement in the CMake testing process that
will benefit not only the CMake project, but also the PLplot project.
Anyhow, Bill and I both hope this test will very much reduce or
eliminate instances like the present one where a CMake issue first
introduced in 3.8.0 RC's somehow slipped through the cracks of all the
normal continuous automatic testing of CMake (see new test suggestion
for UseSWIG.cmake in my previous post in this thread).  Of course, I
am partially responsible for this situation as well because my
near-constant testing of PLplot typically occurs for a fixed version
of CMake that I rarely have time to change since such change does
require a time-consuming build of CMake.  Fortunately, the rarety of
my CMake version changes used for my PLplot testing will no longer be
a problem when the planned continuous integration test goes live so I
am really looking forward to that.

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

[Alan W. Irwin]

On 2017-07-25 17:48-0700 Alan W. Irwin wrote:


More later on those git bisect results when that process is completed.


As per usual, git bisect (along with ccache to speed up the process by
a noticable amount especially in the last 5 steps or so) is awesome.

Here is what it found:

62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit
commit 62c4cb4b6f0cdb2be2729362133f850d6fe96c20
Author: caryoscelus 
Date:   Mon Nov 28 21:46:41 2016 +0300

UseSWIG: Record generated java files as custom command outputs

When another target depends on the generated files CMake must know which
custom command generates them in order to hook up the dependency
properly.  We already do this for Python.  Add the Java files too.

:04 04 0ba5ac99776eb3c196dfe7639dcf6c47711cd204 
135152a2f7229d2a2f63cded6617c5b30f40e9d8 M  Modules
software@raven> git describe
v3.7.0-651-g62c4cb4

The file differences introduced by that change were quite small:

software@raven> git diff 62c4cb4b6f0^ 62c4cb4b6f0
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index c5912f8..651f9f1 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -57,7 +57,8 @@
 set(SWIG_CXX_EXTENSION "cxx")
 set(SWIG_EXTRA_LIBRARIES "")

-set(SWIG_PYTHON_EXTRA_FILE_EXTENSION "py")
+set(SWIG_PYTHON_EXTRA_FILE_EXTENSIONS ".py")
+set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")

 #
 # For given swig module initialize variables associated with it
@@ -123,9 +124,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles 
generatedpath infile)
 endif ()

   endif()
-  foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSION})
+  foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS})
 set(${outfiles} ${${outfiles}}
-  "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}.${it}")
+  "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
   endforeach()
 endmacro()

UseSWIG.cmake is a complex beast, and I frankly don't understand it.

However, for CMake-3.9.0 I tried simply commenting out

set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")

in the installed version of UseSWIG.cmake

and that workaround completely solved the CMake-time issue for PLplot!

Furthermore, when I built our test_diff_psc target (which exercises
our ~30 standard examples written in ~10 different computer languages
and compares the generated PostScript plot results for corresponding
examples in each language, the Java part of that test was perfect,
i.e., each of its standard examples written in Java produced the exact
same result as the corresponding standard example written in C.

To help with finding a real fix for this issue rather than the above
workaround, I have finally came up with a simple test project
that demonstrates the issue.



cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test_java C)
find_package(SWIG)
include(UseSWIG)
enable_language(Java)

# As a simple test of missing Java language support variables try and
# configure a build of a Java module or library from an empty *.i file
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/test_java.i "")
swig_add_library(test_java TYPE MODULE LANGUAGE java SOURCES 
${CMAKE_CURRENT_BINARY_DIR}/test_java.i)


I suggest this test project should be used as a template (possibly
with several other languages substituted for Java, NONE substituted
for C, and TYPE SHARED substituted for MODULE).  Anyhow, here is the
cmake command output for this project with unpatched 3.9.0

-- The C compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12") 
-- Configuring done

CMake Error: Error required internal CMake variable not set, cmake may not be 
built correctly.
Missing variable is:
CMAKE_Java_CREATE_SHARED_MODULE
-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir

If the CMake-3.9.0 installed UseSWIG.cmake file is patched (by
commenting out the line in that file,

set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")

), then the initial cmake output is the same, but the final few lines are

-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12") 
-- Configuring done

-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir

So from these two different results, the conclusion is the above simple project 
file
recreates the bad PLplot results for unpatched CMake-3.9.0 and the good
PLplot results for patched 3.9.0.

Nevertheless, that patch is not a fix but simply a workaround.
Therefore, deeper analysis is needed by someone who really understands
why that one line