MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013474CMakeCMakepublic2012-08-15 11:292014-01-15 10:31
ReporterBrad King 
Assigned ToAlex Neundorf 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 2.8.9 
Target VersionCMake 2.8.10Fixed in VersionCMake 2.8.10 
Summary0013474: CMake Makefile generator does not re-scan dependencies if object fails to build
DescriptionWhile tracking down behavior reported in issue 0013471 I narrowed it down to a test case not involving Fortran. If a source file fails to produce an object file, perhaps due to a compilation error, then the user typically edits it to fix the error. On the next "make" CMake should re-scan dependencies of the modified file. It doesn't always do this. See steps to reproduce.
Steps To Reproduce$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(bug CXX)
add_executable(bug bug.cxx)

$ cat ../bug.hxx
int bug(void) { return 0; }

$ cat ../bug.cxx
//#include "bug.hxx"
int main() { return bug(); }

$ cmake .. && make
...
Scanning dependencies of target bug
[100%] Building CXX object CMakeFiles/bug.dir/bug.cxx.o
.../bug.cxx: In function ‘int main()’:
.../bug.cxx:2:25: error: ‘bug’ was not declared in this scope

$ vi ../bug.cxx && cat ../bug.cxx
#include "bug.hxx"
int main() { return bug(); }

$ make
[100%] Building CXX object CMakeFiles/bug.dir/bug.cxx.o
Linking CXX executable bug
[100%] Built target bug

# The above should have re-scanned. Now it does not know about bug.hxx:

$ touch ../bug.hxx

$ make
[100%] Built target bug

# The above should have re-compiled. One can work around the problem with an explicit "make depend":

$ make depend

$ make
Scanning dependencies of target bug
[100%] Building CXX object CMakeFiles/bug.dir/bug.cxx.o
Linking CXX executable bug
[100%] Built target bug
Additional Information
TagsNo tags attached.
Relationships
related to 0013471closed Brad King CMake does not understand Fortran interface "module procedure" syntax 
related to 0014699closed  Implicity dependency scanner does not not update depend.make in succeeding incremental make builds if a #include was missing 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-08-15 11:29Brad KingNew Issue
2012-08-15 11:30Brad KingRelationship addedrelated to 0013471
2012-08-15 11:34Brad KingAssigned To => Alex Neundorf
2012-08-15 11:34Brad KingStatusnew => assigned
2012-08-15 14:10Amine ChadlyNote Added: 0030673
2012-08-15 14:32Sylwester ArabasNote Added: 0030674
2012-08-15 15:36Alex NeundorfNote Added: 0030675
2012-08-15 15:57Alex NeundorfNote Added: 0030676
2012-08-15 16:27Brad KingNote Added: 0030677
2012-08-16 16:49Alex NeundorfNote Added: 0030686
2012-08-17 17:21Alex NeundorfNote Added: 0030694
2012-08-17 17:21Alex NeundorfStatusassigned => closed
2012-08-17 17:21Alex NeundorfResolutionopen => fixed
2012-08-20 14:10David ColeFixed in Version => CMake 2.8.10
2012-08-20 14:10David ColeTarget Version => CMake 2.8.10
2014-01-15 10:31Brad KingRelationship addedrelated to 0014699

Notes
(0030673)
Amine Chadly   
2012-08-15 14:10   
Hi,
aren't we supposed to declare the app as:
add_executable(bug bug.hxx bug.cxx)
instead of:
add_executable(bug bug.cxx)
To get the desired behavior ?
Kind regards.
(0030674)
Sylwester Arabas   
2012-08-15 14:32   
Hi,
I guess such workaround would not help in case of the behavior described here: http://public.kitware.com/Bug/view.php?id=13471 [^] (an item marked as a less general example of the same issue).
HTH,
Sylwester
(0030675)
Alex Neundorf   
2012-08-15 15:36   
It behaves this way since October 2005: https://github.com/Kitware/CMake/commit/f18e7c7ff7935a93076384ba15629942f559cc8d [^] , which was way before my optmizations. I'll have a look anyway.
(0030676)
Alex Neundorf   
2012-08-15 15:57   
Even longer, it is since this commit from January 2005: https://github.com/Kitware/CMake/commit/195cdf172e2eecdb1b7fb3c2154cfe34c14afd9f [^]

The comment added there says
"// Dependencies must be regenerated if the dependee does not exist
// or if the depender exists and is older than the dependee."

So, what happens in your testcase:
Dependencies are scanned initially, only bug.cxx is found for bug.o . This is correct.
Make tries to build and fails, so bug.o does still not exist.
You edit bug.cxx, and try to build again. The cmake dependency checker now does what the comment says: the dependee (bug.cxx) exists, and the depender (bug.o) does not exist, so it does not rescan.
Maybe it should simply rescan if depend.make or depend.internal do not exist or are older than the dependee ?
(0030677)
Brad King   
2012-08-15 16:27   
Re 0013474:0030676: I think rescanning if depend.(make|internal) are older is the correct solution. Thanks.
(0030686)
Alex Neundorf   
2012-08-16 16:49   
I pushed a fix for this to the DependencyScanning_13474 branch on stage.
(0030694)
Alex Neundorf   
2012-08-17 17:21   
Merged into next.