[CMake] Swig dependencies not being tested?

[James Bigler]

I have a modified version of the Swig module (edited before the 
EXTRA_DEPS flag was present).  It uses the -MM to create dependencies 
and a python script to convert the file into a CMake consumable 
version.  The make2cmake.py file could be rewritten in cmake script (see 
below).  It just needs some regular expression magic.  We've done it for 
other compilers (cuda), but I haven't bothered since I had one that just 
worked.

You can find the code in our online repository.

svn cat 
https://code.sci.utah.edu/svn/Manta/trunk/CMake/MantaUseSWIG.cmake > 
MantaUseSWIG.cmake
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/make2cmake.py > 
make2cmake.py
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/empty.depend.in 
 > empty.depend.in

You don't have to do anything special on the using side.  It can be used 
as a drop in replacement for the existing swig module.  You just have to 
place these three files in a CMake directory at the top of your source tree.

The mechanics were takes from some code I found in VTK.  You create two 
additional targets.  One generates the .swig-depends file via swig -MM.  
The next converts the file to a cmake readable form.  Swig doesn't 
regenerate the .swig-depends file if the dependencies don't change, so 
you get reasonable behavior.  We've been using this script for a couple 
of years now with out problems.

James

P.S. Here's my first stab at a make2cmake.cmake script (note it probably 
isn't complete).

SET(IN_FILENAME "test.swig-depend")
MESSAGE("IN_FILENAME = ${IN_FILENAME}")

FILE(READ ${IN_FILENAME} FILESTUFF)
MESSAGE("FILESTUFF = ${FILESTUFF}")

STRING(REGEX REPLACE "^.*:[ \\\\]*\n" "" FILESTUFF ${FILESTUFF})
STRING(REGEX REPLACE "[ \\\\]*\n" ";" FILESTUFF ${FILESTUFF})
MESSAGE("FIXED = ${FILESTUFF}")

FOREACH(VAR ${FILESTUFF})
  MESSAGE("VAR = ${VAR}")
ENDFOREACH(VAR)

We did get this working for cuda, but the regular expression may need to 
be modified to the one above.

svn cat 
https://code.sci.utah.edu/svn/people/abe/code/CMake-cuda/CMake/cuda/make2cmake.cmake 
 > make2cmake.cmake



On Dec 10, 2007, at 9:08 AM, 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':
>
> SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
> SWIG_ADD_MODULE(foo PYTHON foo.i)
>
>
> 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.
>
> +1
>
>> 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.
>
> -- 
> Tristan Carel
> Music with dinner is an insult both to the cook and the violinist.
> http://www.tristancarel.com
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake