MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010080CMakeModulespublic2009-12-25 07:122015-03-02 08:57
Reportercelil 
Assigned Tojschueller 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 3.0 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0010080: UseSWIG rebuilds source even when the the dependencies have not changed
DescriptionUsing swig to build a python extension, I have a CMakeLists.txt that looks like this

swig_add_module(mod PYTHON mod.i )
swig_link_libraries(mod ${PYTHON_LIBRARIES} ext_lib)

However, with these commands running make rebuilds the _modPYTHON_wrap.cxx and _mod.so every time regardless of whether mod.i has changed or not.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0014859closed jschueller UseSWIG rebuilds source even when the the dependencies have not changed (again) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-12-25 07:12celilNew Issue
2010-12-14 17:08David ColeAssigned To => Mathieu Malaterre
2010-12-14 17:08David ColeStatusnew => assigned
2010-12-14 17:09David ColeNote Added: 0023985
2011-03-28 12:21Mathieu MalaterreNote Added: 0025935
2011-03-28 12:22Mathieu MalaterreStatusassigned => feedback
2012-09-03 22:22Alex TurbovNote Added: 0030905
2012-09-03 22:22Alex TurbovNote Edited: 0030905bug_revision_view_page.php?bugnote_id=30905#r801
2012-09-04 07:12Mathieu MalaterreNote Added: 0030907
2012-09-10 16:39Felix SchwitzerNote Added: 0030989
2014-02-24 10:01Brad KingAssigned ToMathieu Malaterre => jschueller
2014-02-24 10:01Brad KingStatusfeedback => assigned
2014-02-24 10:33Brad KingNote Added: 0035174
2014-02-26 09:33Brad KingStatusassigned => resolved
2014-02-26 09:33Brad KingResolutionopen => fixed
2014-02-26 09:33Brad KingFixed in Version => CMake 3.1
2014-02-26 09:33Brad KingTarget Version => CMake 3.1
2014-03-20 05:12jschuellerNote Added: 0035446
2014-03-20 05:12jschuellerStatusresolved => feedback
2014-03-20 05:12jschuellerResolutionfixed => reopened
2014-03-20 05:14jschuellerNote Edited: 0035446bug_revision_view_page.php?bugnote_id=35446#r1403
2014-03-20 08:58Brad KingNote Added: 0035450
2014-03-20 08:58Brad KingStatusfeedback => assigned
2014-03-20 08:58Brad KingResolutionreopened => open
2014-03-20 08:58Brad KingProduct VersionCMake-2-8 => CMake 3.0
2014-03-20 08:58Brad KingFixed in VersionCMake 3.1 =>
2014-04-01 06:15jschuellerNote Added: 0035595
2014-04-01 06:16jschuellerStatusassigned => closed
2014-04-01 06:16jschuellerResolutionopen => fixed
2014-04-01 09:39jschuellerStatusclosed => resolved
2014-04-01 09:39jschuellerFixed in Version => CMake 3.1
2014-04-02 09:03Brad KingRelationship addedrelated to 0014859
2014-04-15 09:36Brad KingNote Added: 0035708
2014-04-15 09:36Brad KingStatusresolved => assigned
2014-04-15 09:36Brad KingResolutionfixed => open
2014-04-15 09:36Brad KingFixed in VersionCMake 3.1 =>
2014-04-18 08:47jschuellerNote Added: 0035738
2014-04-18 08:56Brad KingNote Added: 0035739
2014-04-18 09:18jschuellerNote Added: 0035742
2014-04-18 09:32Brad KingNote Added: 0035743
2014-04-18 10:58jschuellerNote Added: 0035744
2014-04-18 10:59jschuellerNote Edited: 0035744bug_revision_view_page.php?bugnote_id=35744#r1449
2014-04-21 09:25Brad KingNote Added: 0035749
2014-04-21 09:25Brad KingStatusassigned => resolved
2014-04-21 09:25Brad KingResolutionopen => fixed
2014-04-21 09:25Brad KingFixed in Version => CMake 3.1
2015-03-02 08:57Robert MaynardNote Added: 0038120
2015-03-02 08:57Robert MaynardStatusresolved => closed

Notes
(0023985)
David Cole   
2010-12-14 17:09   
Hey Mathieu, you want this SWIG related issue, too? :-)

(If not, just assign it back to me...)
(0025935)
Mathieu Malaterre   
2011-03-28 12:21   
I need more info to reproduce here. This is working ok for me.

thanks.
(0030905)
Alex Turbov   
2012-09-03 22:22   
Mathieu what kind of info do you need?
I also have this bug in my current project and it's *really* annoyed...
Feel free to ask me any addition info...
(0030907)
Mathieu Malaterre   
2012-09-04 07:12   
As said before, this is working for me on GDCM project for years. I need your specific test case to reproduce and/or understand what /could/ be going on wrong.
(0030989)
Felix Schwitzer   
2012-09-10 16:39   
I observed this behavior also, but
as far as I know this (rebuilding the whole wrapper file and the module)
happens only if the name of the python module and the name
of the interface file are different:

   swig_add_module(mod PYTHON mod.i )
works fine, but
   swig_add_module(ttt PYTHON mod.i)
will not.

My actual workaround is to name the module after the interface file.
(0035174)
Brad King   
2014-02-24 10:33   
Please try out the change Julien Schueller made here:

 UseSWIG: Name extra generated files after module name
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0111deb [^]
(0035446)
jschueller   
2014-03-20 05:12   
(edited on: 2014-03-20 05:14)
The change I did is not good, I reverted it in the fix-0010080 branch.
I'll try a better fix by detecting the module name in the .i file.
(0035450)
Brad King   
2014-03-20 08:58   
Re 0010080:0035446: I rebased the revert back on the original commit and merged to 'next' for testing:

 Revert "UseSWIG: Name extra generated files after module name"
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9760647 [^]
(0035595)
jschueller   
2014-04-01 06:15   
Fixed here:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=63ebb1 [^]
J.
(0035708)
Brad King   
2014-04-15 09:36   
Re 0010080:0035595: Might the .i file be generated and therefore not exist or be out of date when CMake is running? The file(STRINGS) command will fail if the file does not exist.
(0035738)
jschueller   
2014-04-18 08:47   
You're right,
I added guards:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=d8b206 [^]
J.
(0035739)
Brad King   
2014-04-18 08:56   
Re 0010080:0035738: This approach still feels unreliable. Now if the .i is generated this issue will still occur, right?

Why shouldn't the caller have to specify the module name to resolve this?
(0035742)
jschueller   
2014-04-18 09:18   
I agree, and that's what I documented in the header:

"The property SWIG_MODULE_NAME can be used to specify the actual import name of the module in the target language if it cannot be parsed or different from the module file basename."

I thought guessing it automatically is a nice feature and will work for most cases.
(0035743)
Brad King   
2014-04-18 09:32   
Re 0010080:0035742: Please extend the documentation to explain the situation fully (auto-scan when the source exists, required property setting otherwise). Also revise the wording to make it clear that SWIG_MODULE_NAME is a source file property on the .i file. It could even be an example:

 set_property(SOURCE mymod.i PROPERTY SWIG_MODULE_NAME mymod_realname)

Also clarify that it must be set before the invocation of the macro.
(0035744)
jschueller   
2014-04-18 10:58   
(edited on: 2014-04-18 10:59)
I reworked it using sphinx:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=ec68ce11 [^]
(0035749)
Brad King   
2014-04-21 09:25   
I've squashed the topic for this issue down into two commits:

 UseSWIG: Detect module name from interface file
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e147c5c5 [^]

 UseSWIG: Revise and format documentation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c96192f [^]
(0038120)
Robert Maynard   
2015-03-02 08:57   
Closing resolved issues that have not been updated in more than 4 months.