[cmake-developers] [UseSWIG] regression in results from CMake-3.0.2 to recent versions

[Alan W. Irwin]

This is just a preliminary statement of the problem in case someone
else has run into this, but obviously I have lots more work to do
(e.g., implement a grossly simplified test case to allow easy
verification of the problem both for me and others, and if I can
demonstrate the problem occurs for that simple test case, then use git
bisection to find when CMake introduced that regression).

To give some quick background for me (if some of you are not already aware),
I am an experienced CMake builder (with bootstrap method) on Debian
Jessie Gnu/Linux, and I use those resulting cmake executables to build a
number of different complex software projects including my primary
software interest, PLplot.

To give some background with regard to PLplot, that software project
has languages bindings for a number of different languages, and 4 of
those (Python, Java, Lua, and Octave) are generated by swig using the
facilities of CMake's UseSWIG module _without any CMake-related issues
whatsoever_. PLplot also has a really old hand-crafted binding called
plplot_widget that glues together our Python binding and our Tcl/Tk
binding.  This allows someone using the Python language to import
tkinter, plplot (a simple hand-crafted wrapper for plplotc which wraps
_plplotc.so where both the latter two are generated by swig), and the
plplot_widget extension module that glues everything together to
access our Tcl/Tk plot functionality directly from Python.
plplot_widget only works with Python2 and is essentially
unmaintainable (because it is someone else's work from a decade ago
who is no longer with the project).  So instead of getting into the
complications of porting that plplot_widget extension module to
Python3, I decided yesterday to let swig do that job (since
swig-generated bindings work in general both with Python2 and
Python3).  That implementation turned out to be trivial because the
effective C code that was being interfaced was a one-line routine with
a single long int argument. And the result (except for a set of build
warnings for both Python2 and Python3 for modern CMake) works fine for
both Python2 and Python3.

So with those preliminaries done, the issue I need to discuss is the
following build warnings (for the new swig-generated Python module
which consists of Pltk_init which wraps _Pltk_init) that I discovered
for CMake-3.8.0-rc4 (the latest version of that software I have
recently built) and also CMake-3.7.2:

bindings/python/CMakeFiles/_Pltk_init.dir/build.make:77: warning: overriding recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:65: warning: ignoring old recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:77: warning: overriding recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:65: warning: ignoring old recipe for target 'bindings/python/plplotc.py'

These warnings occur when (successfully) building (or rebuilding)
_Pltk_init. A check of those files indicated they were caused by a
part (build rules for plplotc.py) of the _plplotc rules being copied
not once but twice (!) to the unrelated build rules for _Pltk_init.

This case of plplotc Makefile rules contaminating Pltk_init rules occurred for
the case where the Pltk_init CMake UseSWIG-related logic
(swig_add_module, swig_link_libraries, etc.) was placed after the
similar logic for the plplotc case in the relevant CMakeLists.txt
file.  If that order is reversed, the above warnings disappear, but
then you get similar warnings concerning Pltk_init rules contaminating
the plplotc rules!

No such warnings occur for the other (Java, Lua, Octave)
swig-generated bindings so it appears the problem is only triggered if
two library modules are generated with UseSWIG logic and swig in the
same directory.

These warnings completely disappear for CMake-3.0.2!  So there is a
good possibility this is due to an actual regression in CMake rather
than due to some bug in the PLplot build system that only manifests
for recent CMake versions.  In any case, the above
gross-simplification work should decide that issue.

So my next steps are gross simplification (to prove this
cross-contamination of build rules for UseSWIG-generated modules in
the same CMakeLists.txt file really is due to a regression in CMake
somewhere between CMake-3.0.2 and 3.7.2.  Note that both CMake-3.7.2
and CMake-3.8.0-rc4 show the warning problem.) And _if that is
proved_, then git bisect from CMake-3.0.2 to the latest git version to
make sure (a) the issue is not solved in the absolutely latest git
version of CMake and to (b) find exactly where the regression was
introduced.

Meanwhile, to help pin down the cause of the above warning messages
some more before I do the above work, has anybody else here had
trouble (or success) with use of the UseSWIG facilities in the same
directory for two different swig-generated Python modules? Same
question for two different swig-generated modules for the same
language?  Same question for two different swig-generated modules
for different languages?

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
__________________________