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