[CMake] Swig dependencies not being tested?

Hendrik Sattler post at hendrik-sattler.de
Mon Dec 10 15:03:26 EST 2007


Am Montag 10 Dezember 2007 schrieb Tristan Carel:
> 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':
>
> SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
> SWIG_ADD_MODULE(foo PYTHON foo.i)

And there is the whole point: that adds a cmake target "foo" with output 
name "_foo.so". So an
  SWIG_ADD_MODULE(foo PERL foo.i)
conflicts with the first cmake target. Add even an
  SWIG_ADD_MODULE(foo RUBY foo.i)
conflict with the cmake target _and_ the output name of the PERL line. That 
could be improved a lot.

The following recompiles every time:
-----------------------snip--------------------------------
option ( BUILD_BINDINGS "Build the SWIG bindings" )

if ( BUILD_BINDINGS )
  find_package ( SWIG  REQUIRED )
  include (${SWIG_USE_FILE})

  include_directories ( ${CMAKE_CURRENT_SOURCE_DIR} )

  set ( FOO_SWIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/foo.i" )

  set ( CMAKE_SWIG_FLAGS "" )
  set_source_files_properties ( ${FOO_SWIG_FILE} PROPERTIES
    CPLUSPLUS OFF
    SWIG_FLAGS ""
  )

  foreach ( LANG perl python ruby )
    string ( TOUPPER "${LANG}" LANG_UPPERCASE)
    option ( BUILD_${LANG_UPPERCASE}_BINDING "Build the ${LANG} binding" ON )
    include ( ${LANG}/CMakeLists.txt)
  endforeach ( LANG )
endif ( BUILD_BINDINGS )
-----------------------snip--------------------------------

The python/CMakelists.txt then contains:
-----------------------snip--------------------------------
find_package ( PythonLibs )
include_directories ( ${PYTHON_INCLUDE_PATH} )
swig_add_module ( foo_python python ${FOO_SWIG_FILE} )
swig_link_libraries ( foo_python libobexftp )
set_target_properties ( ${SWIG_MODULE_foo_python_REAL_NAME}
  PROPERTIES
  OUTPUT_NAME "_foo"
)
-----------------------snip--------------------------------

You have your example :)
The same for PERL does _not_ recompile every time.

> Attached to #4147, you can  find a macro
> `SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
> to compute dependencies. This intend to replace use of variable
> SWIG_MODULE_<module>_EXTRA_DEPS
>
> Could you please describe a use case which create the unnecessary
> rebuilt of your project?
>
> > > Someone else also pointed out a problem with .i files having to be in
> > > the current source dir.
> >
> > We have never felt constrained by that limitation (in fact I was unaware
> > of it) since it is possible to specify just one *.i file in the current
> > source directory that then includes *.i files from elsewhere in the
> > source tree.
>
> > Despite the convenience of this approach, others will have different
> > needs that would best be served by allowing the initial *.i file (that
> > includes the rest of the *.i files) to be somewhere else than the current
> > source directory so on these general grounds I hope this limitation is
> > removed at the same time as when the dependency problem is fixed.
>
> I agree, it should work.
> I guess it is alright if you specify a path like "../common.i" but not
> something like ${CMAKE_SOURCE_DIR}/swig/common.i.

No, neither works currently.

HS


More information about the CMake mailing list