| Summary: | CMake subprojects lead to duplicated targets in project model | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Venca B Spam <vbspam> |
| Component: | Build tools: CMake | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 5.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kdevelop/c2f9b5f29fa74a0fd8b270c1819dc25fa4855bfd | Version Fixed In: | 5.2.1 |
| Sentry Crash Report: | |||
| Attachments: |
SampleMultiProject
SampleProject Bug report illustration Multiproject parsed by CMake server Illustration of multiproject-cmake-server-response JSON |
||
|
Description
Venca B Spam
2017-11-19 06:32:01 UTC
Created attachment 108955 [details]
SampleMultiProject
Created attachment 108956 [details]
SampleProject
Created attachment 108957 [details]
Bug report illustration
Created attachment 108966 [details]
Multiproject parsed by CMake server
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? If the cmake server reply is already bogus, this bug should be reported upstream against cmake and fixed there, imo 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.
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. 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. 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 I can confirm that in my own KDevelop builld (5.2.40 c2f9b5) it works well now. Thanks for the confirmation! |