MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014579CMakeCMakepublic2013-11-18 05:372016-06-10 14:31
ReporterAdrien Bruneton 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSFedoraOS Version18
Product VersionCMake 2.8.12.2 
Target VersionFixed in Version 
Summary0014579: Dependency check mechanism ignores deleted header files
DescriptionOn Fedora 18, CMake 2.8.10.2, using the default "Unix Makefile" generator, CMake improperly detects the removal (or update) of a C++ header file when it has been manipulated (see below steps to reproduce).

This leads to CMake wrongly believing the project is up-to-date, when it fact some source files have been modified.
Steps To ReproduceThe attached archive provides two files:
  simple.cxx, which includes:
  simple.hxx (no functional content)

Untar the attached archive. Go to the directory. Then execute:

> mkdir BUILD && cd BUILD
> cmake .. && make
> mv ../src/simple.hxx ../src/simple.OLD
> make
  ----> ERROR (as expected)
> mv ../src/simple.OLD ../src/simple.hxx
> make
  ----> OK! (as expected)
> mv ../src/simple.hxx ../src/simple.OLD
  ----> No dependency scanning, no update, no reconstruction!! The build (wrongly) succeeds.
Additional Information
TagsNo tags attached.
Relationships
Attached Filesgz dep_bug.tar.gz (583) 2013-11-18 05:37
https://public.kitware.com/Bug/file/4952/dep_bug.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2013-11-18 05:37Adrien BrunetonNew Issue
2013-11-18 05:37Adrien BrunetonFile Added: dep_bug.tar.gz
2013-11-18 10:42Robert MaynardNote Added: 0034465
2013-11-19 02:42Adrien BrunetonNote Added: 0034475
2014-01-29 10:58Adrien BrunetonNote Added: 0035011
2014-01-29 11:27Brad KingNote Added: 0035012
2014-01-29 11:30Brad KingStatusnew => backlog
2014-01-29 11:30Brad KingProduct VersionCMake 2.8.10.2 => CMake 2.8.12.2
2014-01-29 11:35Brad KingNote Added: 0035013
2016-06-10 14:29Kitware RobotNote Added: 0042427
2016-06-10 14:29Kitware RobotStatusbacklog => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0034465)
Robert Maynard   
2013-11-18 10:42   
I believe that this behavior is been fixed in CMake 2.8.12. Can you verify that?
(0034475)
Adrien Bruneton   
2013-11-19 02:42   
No, I can reproduce the bug with CMake 2.8.12.
(0035011)
Adrien Bruneton   
2014-01-29 10:58   
Up. Can you please provide an update on this? Thanks.
(0035012)
Brad King   
2014-01-29 11:27   
I can reproduce it with the following session:

$ mkdir build && cd build
$ cmake ..
$ make
Scanning dependencies of target simple
[100%] Building CXX object src/CMakeFiles/simple.dir/simple.cxx.o
Linking CXX executable simple
[100%] Built target simple

$ cat src/CMakeFiles/simple.dir/depend.make
src/CMakeFiles/simple.dir/simple.cxx.o: ../src/simple.cxx
src/CMakeFiles/simple.dir/simple.cxx.o: ../src/simple.hxx

$ mv ../src/simple.hxx ../src/simple.OLD
$ make
Scanning dependencies of target simple
[100%] Building CXX object src/CMakeFiles/simple.dir/simple.cxx.o
.../src/simple.cxx:8:22: fatal error: simple.hxx: No such file or directory

$ cat src/CMakeFiles/simple.dir/depend.make
src/CMakeFiles/simple.dir/simple.cxx.o: ../src/simple.cxx

$ mv ../src/simple.OLD ../src/simple.hxx
$ make
[100%] Building CXX object src/CMakeFiles/simple.dir/simple.cxx.o
Linking CXX executable simple
[100%] Built target simple

$ cat src/CMakeFiles/simple.dir/depend.make
src/CMakeFiles/simple.dir/simple.cxx.o: ../src/simple.cxx

$ mv ../src/simple.hxx ../src/simple.OLD
$ make
[100%] Built target simple

When the header is missing the dependency scanning completes and does not list the header. When the header is restored the build completes but no known dependencies are actually out of date so make does not tell CMake to rescan dependencies. Then when the header goes missing again no know dependencies are out of date or missing.
(0035013)
Brad King   
2014-01-29 11:35   
I'm not sure this is possible to fix without major dependency scanning redesign to do separate dependency scanning for each object as it compiles. Separate scanning was tried in the past but is very slow on some filesystems so it was abandoned.

The Ninja generator uses ninja's builtin features for dependency scanning, and those work by asking the compiler to list the files it encounters (gcc -M* options). The Makefile generator cannot use this approach because it must work with compilers that do not have the feature.
(0042427)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.