Bug 293750

Summary: <wrong-target> when creating cmake test
Product: [Applications] kdevelop Reporter: Ricardo Ortiz <ricortiz>
Component: Build tools: CMakeAssignee: kdevelop-bugs-null
Status: RESOLVED UNMAINTAINED    
Severity: major CC: aleixpol, andre.stein.1985, julian, leonardopl, maxime.haselbauer, meyerm, mikko.vainio
Priority: NOR    
Version: 4.6.0   
Target Milestone: 4.2.3   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: picture
Minimal example to reproduce the problem

Description Ricardo Ortiz 2012-02-10 00:34:45 UTC
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
Comment 1 mikko.vainio 2012-04-20 14:30:47 UTC
Seeing this on Fedora 16 x86_64 using distro default versions of KDevelop/CMake/GCC/etc.
Comment 2 Julian Aloofi 2012-06-02 19:03:51 UTC
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
Comment 3 Aleix Pol 2012-06-05 00:16:23 UTC
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!!
Comment 4 Leonardo 2012-06-09 23:05:25 UTC
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.
Comment 5 Julian Aloofi 2012-06-10 11:57:44 UTC
Created attachment 71697 [details]
Minimal example to reproduce the problem

Attached is a minimal example to reproduce this problem as requested by Aleix.
Comment 6 André Stein 2012-09-11 07:12:16 UTC
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.
Comment 7 André Stein 2012-09-27 07:03:56 UTC
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.
Comment 8 maxime.haselbauer 2014-08-01 09:27:17 UTC
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!
Comment 9 Christoph Feck 2014-08-16 13:17:52 UTC
Opening based on assumption that comment #5 provides the requested information.
Comment 10 Milian Wolff 2016-09-07 21:45:31 UTC
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.