I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using the bootstrap method I have always successfully used for other CMake versions (including 3.7.2).
For a complex project (PLplot) which uses swig_add_module and swig_link_libraries to implement our Java binding, I get the following error message at the end of that CMake-3.9.0 output. -- 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 I don't get this error message for CMake-3.7.2. Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it just does not exist. By the way, I have tried the following simple project. cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) project(test_java NONE) enable_language(Java) message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = ${CMAKE_Java_CREATE_SHARED_MODULE}") (I used 3.6.2 for the minimum version because that is what PLplot uses). That project does confirm that both 3.7.2 and 3.9.0 do not define CMAKE_Java_CREATE_SHARED_MODULE. However, both versions failed to generate the above error so a more complex project such as PLplot that, e.g., swig-generates a Java binding for a C library is needed to show the issue. By the way, inserting the following lines in the PLplot top-level CMakeLists.txt file # Temporary workaround for Java language support issue for # CMake-3.9.0 set(CMAKE_Java_CREATE_SHARED_MODULE "this_command_should_never_be_used") has no bad consequences for cmake-3.7.2, i.e., I can build our Java binding and run all our standard Java examples. However, for the 3.9.0 case, the above change avoids the cmake issue, but there are many JNI-related build errors for our Java binding (although none of them mention "this_command_should_never_be_used"). The only cmake-3.8.0 version I have built previously is one of the release candidates. But that passed all tests at the time including building our Java binding and running our Java examples with success so this appears to be a newly introduced issue for 3.9.0.
From these symptoms, I am pretty sure that language support infrastructure
has been upgraded for 3.9.0, but your Java language support has not been consistently upgraded at the same time. If so, the solution is either downgrade your language support infrastructure to be consistent with CMake-3.8.x or to upgrade your Java language support to be consistent with your updated language support for 3.9.0. Once someone has a patch for this issue I would be happy to test it by rebuilding a patched version of CMake-3.9.0 and trying out a build of PLplot with that patched version. 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