MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013186CMakeCMakepublic2012-05-03 09:482012-10-01 13:22
Reporterm42a 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformArch Linux x86_64OSLinuxOS Version3.3.3
Product Version 
Target VersionFixed in Version 
Summary0013186: CMake ignores files with a certain name
DescriptionIn the project Lirch (at https://github.com/m42a/Lirch/tree/cmake-bug [^]), CMake entirely ignores references to the file named core/lirch_qtcore.cpp (even if it doesn't exist). Renaming or moving the file fixes this problem, but referring to the file by different relative paths does not.
Steps To Reproduce0. Install git and QT
1. git clone git://github.com/m42a/Lirch.git [^]
2. mkdir Lirch/build
3. cd Lirch/build
4. git checkout cmake-bug
5. cmake ..
6. make lirch

This fails with an error about not finding main, since core/lirch_qtcore.cpp contains main but was never compiled or linked. If line 30 in core/CMakeLists.txt is changed to reference any file other than lirch_qtcore.cpp, it will either compile or correctly complain about a missing file.
Additional InformationI've also reproduced this on Ubuntu 10.04 with cmake 2.8.0.
TagsNo tags attached.
Relationships
related to 0013190closed Kitware Robot Add CMake Policy to drop automatic source extension search 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-03 09:48m42aNew Issue
2012-05-04 02:44Michael WildNote Added: 0029397
2012-05-04 02:44Michael WildNote Edited: 0029397bug_revision_view_page.php?bugnote_id=29397#r637
2012-05-04 02:58Michael WildNote Added: 0029398
2012-05-04 04:19m42aNote Added: 0029399
2012-05-04 11:21Brad KingRelationship addedrelated to 0013190
2012-05-04 11:24Brad KingNote Added: 0029400
2012-05-04 11:24Brad KingStatusnew => resolved
2012-05-04 11:24Brad KingResolutionopen => suspended
2012-05-04 11:24Brad KingAssigned To => Brad King
2012-10-01 13:22David ColeNote Added: 0031120
2012-10-01 13:22David ColeStatusresolved => closed

Notes
(0029397)
Michael Wild   
2012-05-04 02:44   
To clarify: You are aware that your code creates core/alirch_qtcore.cpp with configure_file() and you are now wondering why CMake doesn't complain about the missing core/lirch_qtcore.cpp file (note the missing "a"). Is that right?

If you change the add_executable() call to use an absolute path (i.e. ${CMAKE_CURRENT_BINARY_DIR}/lirch_qtcore.cpp), CMake will complain about the missing file. It seems like CMake is matching lirch_qtcore.cpp from your add_executable() call against ${CMAKE_CURRENT_SOURCE_DIR}/lirch_qtcore.cpp.in which IMHO is indeed a bug.
(0029398)
Michael Wild   
2012-05-04 02:58   
Found the reason for that strange behaviour: When CMake searches for a source file, it tries to find it in the current source directory and then the current binary directory (if the path is not absolute), and if it doesn't find it directly, it tries to find it by appending a series of suffixes to the file name. The list is:

source files: .c .C .c++ .cc .cpp .cxx .m .M .mm
header files: .h .hh .h++ .hm .hpp .hxx .in .txx

Since it can find your file as ${CMAKE_CURRENT_SOURCE_DIR}/lirch_qtcore.cpp.in, it thinks that this must be a header file (the .in suffix is in the list of header file extensions).

I think the reason as to why .in is in the header suffix list is that people want the .in files to show up in the IDE's so they can edit them, but don't want them to be compiled. And the automatic matching with suffixes, while IMHO a rather undesirable feature, is a historical leftover which probably can't be removed easily because of backwards compatibility. Perhaps future versions could introduce a policy for this? I would be very much in favour of deprecating that rather useless, and sometimes harmful automatism.

The solution in your case is simple: Always use absolute paths.
(0029399)
m42a   
2012-05-04 04:19   
Changing to absolute paths does fix the problem; thank you.

I am aware that the generated file's name has an initial a, but the behavior doesn't change even if that a is removed.
(0029400)
Brad King   
2012-05-04 11:24   
Re 0013186:0029398: Thanks, Michael. I've opened issue 0013190 to request just such a policy. I've thought about doing this before too.

Resolving this issue as "suspended" pending issue 0013190.
(0031120)
David Cole   
2012-10-01 13:22   
Closing resolved issues that have not been updated in more than 4 months.