MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012619CMakeCMakepublic2011-12-12 02:122016-06-10 14:31
Reporterchizhong jin 
Assigned ToAlex Neundorf 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSLinuxOS Version3.0
Product VersionCMake 2.8.5 
Target VersionFixed in Version 
Summary0012619: cmDependsC class Scan ignore same file name
DescriptioncmDependsC use cache for speed up dependences scan. But produce a bug.
When you have two or more file with same name in different directories.
cmDependsC will miss some of file.
Steps To Reproducecreate src tree like this.
xxx/
   t.h
   a.h
   src/
      a.h
      a.cpp
a.cpp include ../t.h && a.h
t.h include a.h
create a CMakeLists.txt "add_executable(a a.cpp)"
then in xxx do
$ mkdir build && cd build && cmake ../src && make
$ cat CMakeFiles/a.dir/depend.internal

we get result like:
CMakeFiles/a.dir/a.cpp.o
 /home/jcz/Desktop/src/test/cmake/samefilename/src/../t.h
 /home/jcz/Desktop/src/test/cmake/samefilename/src/a.cpp
 /home/jcz/Desktop/src/test/cmake/samefilename/src/a.h

no ../a.h
Additional Information
TagsNo tags attached.
Relationships
related to 0010048closed Alex Neundorf ADD_CUSTOM_COMMAND cannot handle multiple IMPLICIT_DEPENDS files 
Attached Filesgz samefilename.tar.gz (396) 2011-12-12 02:24
https://public.kitware.com/Bug/file/4141/samefilename.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2011-12-12 02:12chizhong jinNew Issue
2011-12-12 02:24chizhong jinFile Added: samefilename.tar.gz
2011-12-12 09:32Brad KingAssigned To => Alex Neundorf
2011-12-12 09:32Brad KingStatusnew => assigned
2011-12-18 09:25Alex NeundorfNote Added: 0028000
2011-12-18 09:26Alex NeundorfNote Added: 0028001
2011-12-23 04:13chizhong jinNote Added: 0028059
2012-08-13 14:30Alex NeundorfTarget Version => CMake 2.8.10
2012-08-13 14:46Alex NeundorfRelationship addedrelated to 0010048
2012-10-18 14:06Alex NeundorfTarget VersionCMake 2.8.10 =>
2015-07-14 05:34Matteo SettenviniNote Added: 0039135
2016-06-10 14:28Kitware RobotNote Added: 0041943
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0028000)
Alex Neundorf   
2011-12-18 09:25   
I can reproduce the problem with the attached testcase.
The on-disk cache looks ok though.

You can work around it by including "./a.h" in a.cpp.
(0028001)
Alex Neundorf   
2011-12-18 09:26   
There is actually a comment in the code related to this:
     // Queue the file if it has not yet been encountered and it
      // matches the regular expression for recursive scanning. Note
      // that this check does not account for the possibility of two
      // headers with the same name in different directories when one
      // is included by double-quotes and the other by angle brackets.
      // This kind of problem will be fixed when a more
      // preprocessor-like implementation of this scanner is created.

I haven't tried yet, but I guess this is what applies in this case too.
(0028059)
chizhong jin   
2011-12-23 04:13   
The comment means that a header file is referenced by two different ways.
I haven't hit this problem yet.
But it is a risk if we use cmake's incremental compiling to build dailyrelease.

3ks ^_^
(0039135)
Matteo Settenvini   
2015-07-14 05:34   
// Note that this check does not account for the possibility of two
// headers with the same name in different directories when one
// is included by double-quotes and the other by angle brackets.

I had quite some problems with this, as I installed headers in CMAKE_STAGING_PREFIX, and they were picked up before in-tree source files, even though I was adding the CMAKE_STAGING_PREFIX only as a system include path (resulting in "-isystem" being used by the compiler). This caused often a needless recompilation after a "make install". It was chomping away tens of minutes each time, on a big project.

The workaround I found, was putting this in my CMakeLists.txt:

set(CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE ON
    CACHE INTERNAL "Force CMake to put in-source paths before out-of-tree ones when building deps")

Even though the documentation does not say it explicitly, I've seen by reading CMake's sources that this affects the order in which paths are considered.

Actually, I think there should be a change in policy about this, and it should be ON by default. Most of the time, you want your project file always to have precedence over the others (corner cases might want to turn this off on a project-specific basis, though). Just my 2 cents.

I hope this can be useful to others.
(0041943)
Kitware Robot   
2016-06-10 14:28   
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.