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