Created attachment 68665 [details] picture Version: unspecified (using KDE 4.8.0) OS: Linux I upgraded to v4.2.81 in kubuntu (I have also had build the branch v4.2.81) on another machine and found the same bug. When creating a test with: CREATE_TEST_SOURCELIST(TestDriverSources ${DriverName}.cpp ${FileList}) and add an executable: ADD_EXECUTABLE(${DriverName} ${TestDriverSources}) The target(s) don't show up in the source tree, instead I get a <wrong-target> and nothing can be done on it. This works well on branch v4.2.3. Reproducible: Always Steps to Reproduce: Create a single target with: CREATE_TEST_SOURCELIST(TestDriverSources ${DriverName}.cpp ${FileList}) and add an executable: ADD_EXECUTABLE(${DriverName} ${TestDriverSources}) Actual Results: <wrong-taget> encountered Expected Results: I expect a list of test targets(is there is more than one). OS: Linux (i686) release 3.0.0-12-generic Compiler: gcc
Seeing this on Fedora 16 x86_64 using distro default versions of KDevelop/CMake/GCC/etc.
It looks like this happens when KDevelop is not happy with the file list passed to add_executable. I encountered this problem myself when I tried to add sources that were set in a CMakeLists.txt in a subdirectory. In the toplevel CMakeLists.txt I did: add_subdirectory(${CMAKE_SOURCE_DIR}/src) add_executable (foo ${FOO_SOURCES}) and in the CMakeLists.txt in ${CMAKE_SOURCE_DIR}/src I just did: set(FOO_SOURCES # some source files, e.g: ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp PARENT_SCOPE) However, displaying the correct target works when setting FOO_SOURCES in the toplevel CMakeLists.txt (and plain cmake will build the project just fine in either case) PS: I'm using this on Fedora 17, with KDevelop 4.3.1 and CMake 2.8.8
Yes, the <wrong-target> thing appears when there are too few arguments reported, so most likely it couldn't find the ${TestDriverSources} variable's value (like happened to Julian). Can you please put a code that reproduces it? This would help me solve your problem, since I already tried without results. Thanks!!
I also have this problem. This error occurs when I set up a variable with the PARENT_SCOPE option in another CMakeLists.txt file. As the variable is set up in another CMakeLists.txt the parser cannot find it. A solution would be parse the files in the add_subdirectory() statement before resolve the variables, so that all the variable would be mapped with theirs value and the error would not occur.
Created attachment 71697 [details] Minimal example to reproduce the problem Attached is a minimal example to reproduce this problem as requested by Aleix.
I have the same problem. Using a custom function I parse a .vcproj Visual Studio file to get the needed source files. Like Leonardo, the output variable is set using PARENT_SCOPE. The target in kdevelop is then just <wrong-target>. Would it be possible to collect the source files after the first CMake run? This way the sources have already been "calculated" by the build system and more complex expressions or functions work just fine without any changes to the Kdevelop cmake parser.
What about this idea: Cmake allows to generate a json file (compile_commands.json) which contains all source files along its build command in a JSON array: [ { "directory": "/home/stone/Documents/stone-files/steinsoft/projects/android/rockfall/src/jni/build", "command": "/usr/bin/c++ -pedantic -Wall -I/home/stone/Documents/stone-files/steinsoft/projects/android/rockfall/src/jni/rockfall -I/home/stone/Documents/stone-files/steinsoft/projects/android/rockfall/src/jni/inc -I/usr/include/irrlicht -o CMakeFiles/rockfall.dir/unix/main.cpp.o -c /home/stone/Documents/stone-files/steinsoft/projects/android/rockfall/src/jni/unix/main.cpp", "file": "/home/stone/Documents/stone-files/steinsoft/projects/android/rockfall/src/jni/unix/main.cpp" }, ... ] The file will be automatically generated when -DCMAKE_EXPORT_COMPILE_COMMANDS=on is specified during cmake configuration. This way we could ask the build system itself anytime the cmake parser fails to get all information needed.
It has been 2 years since the request for information has been fullfilled It has been 3 release inbetween (was kdevelop 4.3.0 we are 4.6.0) Still this bug is there (and most likely causing other bugs I have reported) So what is the point? Is it left on "Wainting for info" just to polish the stats? If the dev need some more info they should ask it If they have enough info they should remove that stauts. but anyway PLEASE SOMEONE DO SOMETHING!
Opening based on assumption that comment #5 provides the requested information.
We completely removed the old cmake parsing logic for KDevelop 5 and will work on integrating the cmake server in the future (see e.g. http://cppcast.com/2016/08/stephen-kelly/ or https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/). This bug only applies to KDevelop 4, but we don't have to resources to maintain it and instead push our effort into KDev 5. I hope you understand that I'm thus closing this report.