View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013572CMakeCMakepublic2012-10-04 19:512012-10-24 17:30
ReporterCraig Scott 
Assigned ToAlex Neundorf 
PrioritynormalSeverityminorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformLinuxOSFedoraOS Version16
Product VersionCMake 2.8.9 
Target VersionCMake 2.8.10Fixed in VersionCMake 2.8.10 
Summary0013572: Automoc can list moc_*.cpp files twice in ..._automoc.cpp
DescriptionIf you include the C++ headers in the source files for add_executable() or add_library, I've encountered situations where CMake's automoc support then creates duplicate entries in the (target)_automoc.cpp file it creates. It is as though it identifies the moc_(sourcefile).cpp that it needs from the .cpp files in the source file list, but then finds the same set of moc_(sourcefile).cpp files again when it processes the .h files in the source file list. The result is that the build fails with the compiler complaining about redefinition of whatever the moc_(sourcefile).cpp files provide.
Steps To ReproduceThe problem isn't always reproduceable, but once it does occur, it seems that it keeps occurring. I've not found any way to reliably trigger or not trigger the issue, unfortunately. I've had cases where I've been building with the headers included in the source list for months. Then I change something and I start getting the duplicate problem. Today, it seems I can omit the headers from the source file list and that seems to work. Not sure if that's a solution in general, but it would seem that headers should be allowed to be included in the source file list (I believe this was actually necessary for some earlier versions of CMake and using some combination of features needed for Qt support).
Additional InformationSeen with CMake 2.8.8 and 2.8.9.
Tagsqt
Attached Filestxt file icon CMakeLists.txt [^] (270 bytes) 2012-10-08 18:27 [Show Content]
? file icon someclass.h [^] (388 bytes) 2012-10-08 18:27
cpp file icon someclass.cpp [^] (326 bytes) 2012-10-08 18:27
gz file icon automoc_13572.tar.gz [^] (823 bytes) 2012-10-10 15:12

 Relationships

  Notes
(0031179)
Craig Scott (reporter)
2012-10-04 19:54

 One example of where you might want to have your .h files included in the source list is to have those files automatically found as part of your project by IDE's (in my case, Qt creator, but probably also Visual Studio at a guess).
(0031194)
Alex Neundorf (developer)
2012-10-08 15:34

 Can you create a small testcase and attach it here ?
I'd still like to get this fixed for 2.8.10.
(0031195)
Craig Scott (reporter)
2012-10-08 18:28

 The attached set of files reproduced the problem for me. No guarantees it will for you too though!
(0031206)
Alex Neundorf (developer)
2012-10-10 15:14

 The files you attached didn't build for me, I had to adjust a few things (linking against Qt, moving main() to a separate file).
Now it builds, and doesn't show any problems.
I attached my modified version as tar.gz.
Can you try with this one too ?
(0031208)
Alex Neundorf (developer)
2012-10-10 15:36

 Can you maybe attach such a build directory where it fails ?
(0031209)
Alex Neundorf (developer)
2012-10-10 15:47

 Or are symbolic links or something like this in the path to the source dir ?
(0031212)
Alex Neundorf (developer)
2012-10-10 16:06

 A std::map<std::string, std::string> is used to map from headerfiles to the moc file names. The header file names which are used are absolute paths.
This guarantees that the same header file appears only once in this map, but it doesn't guarantee that the same moc file appears only once.
E.g. if you have both a someclass.H and a someclass.h, and list someclass.H as a source file, the automatic searching will also find someclass.h, both will have the same moc file name (moc_someclass.cpp) and so the entry would be twice in the automoc file, and you'd get redefinition of the function.

The other option is that the same file appears twice with a slightly different absolute path in the map. This might maybe happen with a case-insensitive filesystem ?
Or maybe somehow with symbolic links ?
Or maybe if the directory is mounted via automount, and mount points changed in the background ?

Does any of these options sound like it could be your case ?

Alex
(0031213)
Craig Scott (reporter)
2012-10-10 17:29

 I'll have to try the files you provided when I get to work. Your last comment suggests the likely scenario though. I build on a (fixed) mounted drive which I access through a symbolic link. It is possible (likely?) that the CMake project sees the symbolic link path and also the full absolute path and tries to process both. For this particular problem, it would seem better for CMake to always use the full absolute path (ie resolve symbolic links) when trying to work out whether two files are the same.
(0031214)
Craig Scott (reporter)
2012-10-10 20:36

 Argh, yes, sorry about all those build errors! Pulled together the test case in a bit of a hurry. ;)

I've tested running builds via the symbolically linked path and also directly from the absolute path and I can confirm that this seems to be the issue. If I cd into the build tree via the symbolically linked path and run cmake/make, I get the problem as originally reported. If instead I cd into the build tree via the absolute path, I have no problems with the build.
(0031232)
Alex Neundorf (developer)
2012-10-14 15:29

 I just merged a fix into the cmake next branch, I hope this will still make it into 2.8.10 (2.8.10rc2 probably).
If it still doesn't work for you as expected, please reopen this ticket.

 Issue History
Date Modified Username Field Change
2012-10-04 19:51 Craig Scott New Issue
2012-10-04 19:52 Craig Scott Tag Attached: qt
2012-10-04 19:54 Craig Scott Note Added: 0031179
2012-10-07 13:58 Alex Neundorf Assigned To => Alex Neundorf
2012-10-07 13:58 Alex Neundorf Status new => assigned
2012-10-08 15:34 Alex Neundorf Note Added: 0031194
2012-10-08 18:27 Craig Scott File Added: CMakeLists.txt
2012-10-08 18:27 Craig Scott File Added: someclass.h
2012-10-08 18:27 Craig Scott File Added: someclass.cpp
2012-10-08 18:28 Craig Scott Note Added: 0031195
2012-10-10 15:12 Alex Neundorf File Added: automoc_13572.tar.gz
2012-10-10 15:14 Alex Neundorf Note Added: 0031206
2012-10-10 15:36 Alex Neundorf Note Added: 0031208
2012-10-10 15:47 Alex Neundorf Note Added: 0031209
2012-10-10 16:06 Alex Neundorf Note Added: 0031212
2012-10-10 17:29 Craig Scott Note Added: 0031213
2012-10-10 20:36 Craig Scott Note Added: 0031214
2012-10-14 15:29 Alex Neundorf Note Added: 0031232
2012-10-14 15:29 Alex Neundorf Status assigned => closed
2012-10-14 15:29 Alex Neundorf Resolution open => fixed
2012-10-24 17:30 David Cole Fixed in Version => CMake 2.8.10
2012-10-24 17:30 David Cole Target Version => CMake 2.8.10

Copyright © 2000 - 2018 MantisBT Team