View Issue Details Jump to Notes ] Print ]
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
TagsNo tags attached.
Attached Files

 Relationships
related to 0013471closedBrad 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 

  Notes
(0030673)
Amine Chadly (reporter)
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 (reporter)
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 (developer)
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 (developer)
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 (manager)
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 (developer)
2012-08-16 16:49

I pushed a fix for this to the DependencyScanning_13474 branch on stage.
(0030694)
Alex Neundorf (developer)
2012-08-17 17:21

Merged into next.

 Issue History
Date Modified Username Field Change
2012-08-15 11:29 Brad King New Issue
2012-08-15 11:30 Brad King Relationship added related to 0013471
2012-08-15 11:34 Brad King Assigned To => Alex Neundorf
2012-08-15 11:34 Brad King Status new => assigned
2012-08-15 14:10 Amine Chadly Note Added: 0030673
2012-08-15 14:32 Sylwester Arabas Note Added: 0030674
2012-08-15 15:36 Alex Neundorf Note Added: 0030675
2012-08-15 15:57 Alex Neundorf Note Added: 0030676
2012-08-15 16:27 Brad King Note Added: 0030677
2012-08-16 16:49 Alex Neundorf Note Added: 0030686
2012-08-17 17:21 Alex Neundorf Note Added: 0030694
2012-08-17 17:21 Alex Neundorf Status assigned => closed
2012-08-17 17:21 Alex Neundorf Resolution open => fixed
2012-08-20 14:10 David Cole Fixed in Version => CMake 2.8.10
2012-08-20 14:10 David Cole Target Version => CMake 2.8.10
2014-01-15 10:31 Brad King Relationship added related to 0014699


Copyright © 2000 - 2018 MantisBT Team