|
Notes |
|
|
(0031179)
|
|
Craig Scott
|
|
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
|
|
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
|
|
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
|
|
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
|
|
2012-10-10 15:36
|
|
|
Can you maybe attach such a build directory where it fails ? |
|
|
|
(0031209)
|
|
Alex Neundorf
|
|
2012-10-10 15:47
|
|
|
Or are symbolic links or something like this in the path to the source dir ? |
|
|
|
(0031212)
|
|
Alex Neundorf
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
CMakeLists.txt (270) 2012-10-08 18:27
someclass.h (388) 2012-10-08 18:27
someclass.cpp (326) 2012-10-08 18:27
automoc_13572.tar.gz (823) 2012-10-10 15:12