Bug 387095 - CMake subprojects lead to duplicated targets in project model
Summary: CMake subprojects lead to duplicated targets in project model
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: CMake (show other bugs)
Version: 5.2.0
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-19 06:32 UTC by Venca B Spam
Modified: 2017-11-20 08:31 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 5.2.1


Attachments
SampleMultiProject (10.58 KB, application/zip)
2017-11-19 06:32 UTC, Venca B Spam
Details
SampleProject (1.57 KB, application/zip)
2017-11-19 06:32 UTC, Venca B Spam
Details
Bug report illustration (445.13 KB, video/mp4)
2017-11-19 06:37 UTC, Venca B Spam
Details
Multiproject parsed by CMake server (5.15 KB, application/json)
2017-11-19 18:09 UTC, Venca B Spam
Details
Illustration of multiproject-cmake-server-response JSON (1.22 MB, video/mp4)
2017-11-19 21:00 UTC, Venca B Spam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Venca B Spam 2017-11-19 06:32:01 UTC
Since KDevelop 5.2.x release CMake target items in the project tree view are shown twice.

*How to reproduce?*
1. Open attached sample project "SampleMultiProject".
2. Build it.
3. Observe project tree view.

*What happens?*
There is doubled representation shown next to each other of each CMake generated target.

*Expected behavior?*
There should be single representation of each CMake generated target.

*Notes:*
- The test case applied to simple scenario does not suffer this bug. Please see attached "SampleProject". Although it may disqualify this bug report, but I do not see any CMake related issue with the multiproject case.

- Also the previous 5.1.x releases did not suffered by this bug.

- My system is using Clang 5.x/6.x, CMake 3.8 with server support, KDevelop 5.2.0 (also tested with recent homemade build from sources 5.2.40.)
Comment 1 Venca B Spam 2017-11-19 06:32:29 UTC
Created attachment 108955 [details]
SampleMultiProject
Comment 2 Venca B Spam 2017-11-19 06:32:55 UTC
Created attachment 108956 [details]
SampleProject
Comment 3 Venca B Spam 2017-11-19 06:37:16 UTC
Created attachment 108957 [details]
Bug report illustration
Comment 4 Venca B Spam 2017-11-19 18:09:18 UTC
Created attachment 108966 [details]
Multiproject parsed by CMake server
Comment 5 Venca B Spam 2017-11-19 18:56:27 UTC
I did some investigation and it seems that the CMake project is ok. It contains exactly what I would expect.

There is however one clue which may help to find out what changed in KDevelop interpretation of the CMake output. I noticed that the "superproject" contains all targets of all "subprojects". And all "subprojects" they contain their targets as one would expect. 

As the superproject contains all subprojects' targets, they are in the fact in the CMake server "codemodel" reply twice. For details please see attached https://bugs.kde.org/attachment.cgi?id=108966 saved JSON response (Firefox can be used to visualize the file).

I go for bisect now, however if anyone has an idea where to look to, would be nice?
Comment 6 Milian Wolff 2017-11-19 20:13:15 UTC
If the cmake server reply is already bogus, this bug should be reported upstream against cmake and fixed there, imo
Comment 7 Venca B Spam 2017-11-19 21:00:46 UTC
Created attachment 108968 [details]
Illustration of multiproject-cmake-server-response JSON

I am not sure if the CMake output is wrong. It looks they want to keep scopes. The thing is that this technique "project-in-project" is completely legal in CMake.

The core issue here is that in CMake you can have multiple projects in a single build system. Looks like KDevelop idea of a "project" does not match the CMake one.

In order to make the issue easier to understand please see attached screenrecording of the JSON response.
Comment 8 Venca B Spam 2017-11-19 21:06:32 UTC
Although it looks to me now as a bit more complex design issue, the KDevelop release 5.1.x was ok, at least from the user experience perspective.
Comment 9 Milian Wolff 2017-11-19 21:26:00 UTC
Ah, now I see - thanks for the clarifications. I still find it very suspect that CMake lists the targets multiple times. Anyhow, this can probably be workarounded somehow in KDevelop's cmake server import job. I'll have a quick look now.
Comment 10 Milian Wolff 2017-11-19 22:23:01 UTC
Git commit c2f9b5f29fa74a0fd8b270c1819dc25fa4855bfd by Milian Wolff.
Committed on 19/11/2017 at 22:21.
Pushed by mwolff into branch '5.2'.

Don't add the same targets multiple times for nested CMake projects

When we import a cmake project folder and that contains nested
CMake projects, we ended up showing the same target multiple times,
since the CMake server output will reference the same targets for
the parent project and then again for the nested project(s).

Ensure the targets are only added once to fix this issue.

M  +6    -0    plugins/cmake/cmakeprojectdata.h
M  +8    -1    plugins/cmake/cmakeserverimportjob.cpp

https://commits.kde.org/kdevelop/c2f9b5f29fa74a0fd8b270c1819dc25fa4855bfd
Comment 11 Venca B Spam 2017-11-20 04:04:07 UTC
I can confirm that in my own KDevelop builld (5.2.40 c2f9b5) it works well now.
Comment 12 Kevin Funk 2017-11-20 08:31:29 UTC
Thanks for the confirmation!