[CMake] Swig dependencies not being tested?

Tristan Carel tristan.carel at gmail.com
Tue Dec 11 04:59:36 EST 2007


On Dec 10, 2007 8:58 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2007-12-10 17:08+0100 Tristan Carel wrote:
>
> > On Dec 10, 2007 7:15 AM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> >> On 2007-12-10 05:33+0100 Christiaan Putter wrote:
> >>
> >>> Hi all,
> >>>
> >>> I know swig support isn't all that great at the moment but was wondering if
> >>> someone happens to have a working Swig module for cmake that doesn't rebuild
> >>> every time even without the dependencies having changed.
> >>
> >> I do confirm that is a problem, and I hope somebody fixes it.
> >>
> >
> > I use the Swig module, the one provided by CMake, and it's working
> > well. Swig wrappers generation and library compilation are properly
> > managed (not rebuild all the time). I use it the same way than Alan
> > described: only one swig file, which takes care of all inclusions, is
> > provided to the macro SWIG_ADD_MODULE. To specify missing
> > dependencies, I use the variable `SWIG_MODULE_<module>_EXTRA_DEPS':
>
> One weakness of the previous PLplot implementation was the lack of
> dependency on the common file, but now I am using
> SWIG_MODULE_<module>_EXTRA_DEPS to provide that.  Thanks for drawing my
> attention to that possibility.
>
> However, that is a side issue from the problem that swig is always re-invoked
> (for the PLplot case) which means the interface always gets rebuilt.  Here
> are some more details.
>
> CMakeLists.txt fragment:
>
> # This is currently the include list for swig, the C wrapper and the
> # the Python headers. Not particular pretty...
> set(python_interface_INCLUDE_PATHS
> ${CMAKE_SOURCE_DIR}/include
> ${CMAKE_BINARY_DIR}
> ${CMAKE_BINARY_DIR}/include
> ${CMAKE_CURRENT_BINARY_DIR}
> ${PYTHON_INCLUDE_PATH}
> ${CMAKE_SOURCE_DIR}/bindings/swig-support
> )
> include_directories(${python_interface_INCLUDE_PATHS})
>
> set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON -python)
>
> set(CMAKE_SWIG_OUTDIR ${CMAKE_CURRENT_BINARY_DIR})
>
> set(SWIG_MODULE_plplotcmodule_EXTRA_DEPS
> ${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i)
>
> # Set up swig + c wrapper.
> # N.B. the python target has an underscore prepended automatically.
> swig_add_module(plplotcmodule python plplotcmodule.i)
>
> swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES})
>
> If I rerun make, here is the (partial) verbose result showing that swig is
> re-run, then the interface is rebuilt:
>
> [...]
>
> I get the same gratuitous rebuild behaviour for our Java interface as well.
>
> Tristan, since you do not encounter this problem, are you doing something
> qualitatively different than above in your CMakeLists.txt file?

I use `UseSWIG' the same way you do (except the unecessary `-python'
in CMAKE_SWIG_FLAGS, already added by the module when you specify the
target language in SWIG_ADD_MODULE macro). `UseSWIG.cmake' intends to
be smart and takes cares of *all* files generated by swig: not only
c/c++ code, but also wrappers in target language.

UseSwig.cmake uses basename of swig file to determine target language files.

So, do you have %module plplotcmodule or %module plpotc in the plplotcmodule.i?


This constraint on the filename can be quite inconvenient, furthermore
this does not work with Java wrappers :)
so here is a patch:

--- /home/carel/CMake/CMake/Modules/UseSWIG.cmake       2007-03-05
21:21:49.000000000 +0100
+++ /usr/local/share/cmake-2.5/Modules/UseSWIG.cmake    2007-12-11
10:31:38.000000000 +0100
@@ -18,7 +18,8 @@
 SET(SWIG_CXX_EXTENSION "cxx")
 SET(SWIG_EXTRA_LIBRARIES "")

-SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION "py")
+SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION ".py")
+SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")

 #
 # For given swig module initialize variables associated with it
@@ -48,9 +49,15 @@
 #

 MACRO(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile)
-  FOREACH(it ${SWIG_PYTHON_EXTRA_FILE_EXTENSION})
+  GET_SOURCE_FILE_PROPERTY(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
+    ${infile} SWIG_MODULE_NAME)
+  IF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL "NOTFOUND")
+    GET_FILENAME_COMPONENT(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
"${infile}" NAME_WE)
+  ENDIF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL "NOTFOUND")
+  FOREACH(it ${SWIG_${language}_EXTRA_FILE_EXTENSION})
     SET(${outfiles} ${${outfiles}}
-      "${generatedpath}/${infile}.${it}")
+      "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
   ENDFOREACH(it)
 ENDMACRO(SWIG_GET_EXTRA_OUTPUT_FILES)

@@ -105,7 +112,7 @@
   SWIG_GET_EXTRA_OUTPUT_FILES(${SWIG_MODULE_${name}_LANGUAGE}
     swig_extra_generated_files
     "${swig_outdir}"
-    "${swig_source_file_name_we}")
+    "${infile}")
   SET(swig_generated_file_fullname
     "${swig_generated_file_fullname}/${swig_source_file_name_we}")
   # add the language into the name of the file (i.e. TCL_wrap)


So in case the module name is different than the file's basename, you
can add a property SWIG_MODULE_NAME to swig files provided to the
`SWIG_ADD_MODULE' macro in order to force the module name defined by
these files:

SET_SOURCE_FILES_PROPERTIES(callback.i PROPERTIES SWIG_MODULE_NAME Callbacks)
# [...]
SWIG_ADD_MODULE(callback_module python callback.i ...)


> In particular do you set either/both of CMAKE_SWIG_FLAGS and
> CMAKE_SWIG_OUTDIR?  There might be some issue in the dependency logic when
> those variables are set which causes the gratuitous rebuild.

I would be glad to know if it resolves your dependencies problem.

bye
-- 
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UseSwig.cmake.diff
Type: application/octet-stream
Size: 1596 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20071211/1d9e1863/UseSwig.cmake-0001.obj


More information about the CMake mailing list