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 <caryosce...@gmx.com>
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.
:040000 040000 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 generates a check for the existence of the
CMAKE_Java_CREATE_SHARED_MODULE (or CMAKE_Java_CREATE_SHARED_LIBRARY
if the project builds swig-generated libraries rather than modules).
And if that line is commented out that check does not occur for both
the simple project and PLplot project, and, in the PLplot case,
perfect results are created at run time even though the
CMAKE_Java_CREATE_SHARED_MODULE variable is completely missing.
In sum, I have whittled down the demonstration of the issue to a
simple test project which generates the problem or not depending on
the existence of one line in UseSWIG.cmake. And I hope these much
more definite and easy to confirm results will inspire a quick
resolution for this issue. But if timely resolution is not possible, then I
plan to generate a new bug on your bugtracker with the above simple
project as an illustration, and let you guys sort it out as
your time permits.
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
