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 

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 15:00-0700 Alan W. Irwin wrote:


I was hoping some CMake developer here could remember a fairly recent
language support infrastructure change in the run-up to 3.9.0 that is
likely causing this issue, and better yet could immediately think of
the Java language support changes that would need to be made to be
consistent with that hypothesized language support infrastructure
change.  But if nobody gets back to me on that question soon, then I
will go ahead and do a git bisect to help find the commit where the
Java language support issue first showed up.


Oops.

I discovered during the initial stages of that git bisect process that
3.8.0-rc4 is bad while 3.7.2 is good when using the latest git master
branch version of PLplot. That result surprised me (since I do recall
testing 3.8.0-rc4/ without issues), So my testing of 3.8.0-rc4 may not
have included java or some PLplot change between that test and now may
be affecting this good/bad result (although I think that is fairly
unlikely because I don't recall any specific java-related PLplot
changes during that period),

Anyhow, I am now bisecting between CMake 3.7.2 and 3.8.0-rc4 using a 
consistent PLplot version (the tip of our master branch) that is quite

well tested for CMake-3.7.2.  And if anyone here is attempting to
remember relevant language support changes, you should be thinking
about the period between 3.7.2 and 3.8.0-rc4.

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

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 07:45-0400 David Cole wrote:


Alan, you had said in your original post:

"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."

Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with 
the name of the language.

Just a hint about how to further the investigation. I'm curious what the result 
will be, but don't have time right now to dig in on something peripheral to my 
main to do list.


Hi David:

For a v3.8.2 checkout from the release branch, here are the results
for such a search with certain specific language results excluded as
well as results from cmake.vim which listed a very large line.

software@raven> find . -type f -print0 |xargs -0 grep _CREATE_SHARED_MODULE |grep -vE '_(C|CXX|Fortran|CUDA|CSharp|ASM\${ASM_DIALECT})_CREATE_SHARED_MODULE' |grep -v cmake.vim 
Binary file ./.git/index matches

./Help/manual/cmake-variables.7.rst:   /variable/CMAKE_LANG_CREATE_SHARED_MODULE
./Help/variable/CMAKE_LANG_CREATE_SHARED_MODULE.rst:CMAKE__CREATE_SHARED_MODULE
./Source/cmGeneratorTarget.cxx:  return "CMAKE_" + lang + 
"_CREATE_SHARED_MODULE";
./Source/cmMakefileLibraryTargetGenerator.cxx:  linkRuleVar += 
"_CREATE_SHARED_MODULE";
./Modules/Platform/Windows-GNU.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/CYGWIN-GNU.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/Windows-MSVC.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE 
${CMAKE_${lang}_CREATE_SHARED_LIBRARY})
./Modules/Platform/Windows-Embarcadero.cmake:  
set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/Windows-Embarcadero.cmake:
${CMAKE_${lang}_CREATE_SHARED_MODULE}
./Modules/CMakeAddNewLanguage.txt:   CMAKE_(LANG)_CREATE_SHARED_MODULE

Here are the corresponding results for v3.9.0 (without the cmake.vim
exclusion since that file does not appear to be present in that release).

software@raven> find . -type f -print0 |xargs -0 grep _CREATE_SHARED_MODULE 
|grep -vE '_(C|CXX|Fortran|CUDA|CSharp|ASM\${ASM_DIALECT})_CREATE_SHARED_MODULE'
Binary file ./.git/index matches
./Help/manual/cmake-variables.7.rst:   /variable/CMAKE_LANG_CREATE_SHARED_MODULE
./Help/variable/CMAKE_LANG_CREATE_SHARED_MODULE.rst:CMAKE__CREATE_SHARED_MODULE
./Source/cmGeneratorTarget.cxx:  return "CMAKE_" + lang + 
"_CREATE_SHARED_MODULE";
./Source/cmMakefileLibraryTargetGenerator.cxx:  linkRuleVar += 
"_CREATE_SHARED_MODULE";
./Modules/Platform/Windows-GNU.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/CYGWIN-GNU.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/Windows-MSVC.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE 
${CMAKE_${lang}_CREATE_SHARED_LIBRARY})
./Modules/Platform/Windows-Embarcadero.cmake:  
set(CMAKE_${lang}_CREATE_SHARED_MODULE
./Modules/Platform/Windows-Embarcadero.cmake:
${CMAKE_${lang}_CREATE_SHARED_MODULE}
./Modules/Platform/Windows-PGI.cmake:  set(CMAKE_${lang}_CREATE_SHARED_MODULE 
"${CMAKE_${lang}_CREATE_SHARED_LIBRARY}")
./Modules/CMakeAddNewLanguage.txt:   CMAKE_(LANG)_CREATE_SHARED_MODULE

I don't spot any differences between (working) CMake-3.8.x and
(non-working) CMake-3.9.0 except for some new Windows-PGI support
which is not relevant to this problem.

The error message I got was

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


Further finding and grepping found the function (in
Source/cmMakefile.cxx) that emitted that error message which is
defined as follows:

const char* cmMakefile::GetRequiredDefinition(const std::string& name) const
{
  const char* ret = this->GetDefinition(name);
  if (!ret) {
cmSystemTools::Error("Error required internal CMake variable not "
 "set, cmake may not be built correctly.\n",
 "Missing variable is:\n", name.c_str());
return "";
  }
  return ret;
}

A further check

software@raven> find . -type f -print0 |xargs -0 grep GetRequiredDefinition |wc 
-l
52

showed ~50 calls of that function, and I don't know which one of those
calls is generating this error message for 3.9.0 but not for
a release candidate for 3.8.0 (nor for 3.7.2).  But presumably that
call is somewhere down the call stack from the two mentions of
_CREATE_SHARED_MODULE shown above that are in Source.

I was hoping some CMake developer here could remember a fairly recent
language support infrastructure change in the run-up to 3.9.0 that is
likely causing this issue, and better yet could immediately think of
the Java language support changes that would need to be made to be
consistent with that hypothesized language support infrastructure
change.  But if nobody gets back to me on that question soon, then I
will go ahead and do a git bisect to help find the commit where the
Java language support issue first showed up.  (I have been reluctant
to 

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

[David Cole via cmake-developers]

Alan, you had said in your original post:

"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."

Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with 
the name of the language.

Just a hint about how to further the investigation. I'm curious what the result 
will be, but don't have time right now to dig in on something peripheral to my 
main to do list.


David C.


> On Jul 25, 2017, at 5:07 AM, Eric Noulard  wrote:
> 
> 
> 
> 2017-07-22 0:23 GMT+02:00 Alan W. Irwin :
>> 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'm curious with that.
> I do currently use UseJava.cmake module
> https://cmake.org/cmake/help/v3.7/module/UseJava.html
> for building some java bits in a globally C++ project.
> 
> I never tried  enable_language(Java)
> what is the status of Java support as a primary language?
> 
> I tried to find informations about that in the doc and mailing list but 
> didn't find much.
> 
> Could someone please point me to the appropriate place concerning this?
> 
> 
> -- 
> Eric
> -- 
> 
> 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
-- 

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

[Eric Noulard]

2017-07-22 0:23 GMT+02:00 Alan W. Irwin :

> 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'm curious with that.
I do currently use UseJava.cmake module
https://cmake.org/cmake/help/v3.7/module/UseJava.html
for building some java bits in a globally C++ project.

I never tried  enable_language(Java)
what is the status of Java support as a primary language?

I tried to find informations about that in the doc and mailing list but
didn't find much.

Could someone please point me to the appropriate place concerning this?


-- 
Eric
-- 

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

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

[Alan W. Irwin]

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