Bug 482745 - Support Ninja Multi-Config CMake generator
Summary: Support Ninja Multi-Config CMake generator
Status: REPORTED
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: CMake (other bugs)
Version First Reported In: 5.7.211203
Platform: Other All
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-07 16:37 UTC by krizdjali+kdebugs
Modified: 2024-03-07 23:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krizdjali+kdebugs 2024-03-07 16:37:36 UTC
SUMMARY
CMake has supported the Ninja Multi-Config generator for quite a long time now. It's documented here https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html. Like the plain Ninja generator, it creates files for ninja, but instead of setting up just one configuration like the Makefiles generators, it can set up several like the Visual Studio or Xcode generators. As well as making it quicker and more convenient to switch between configurations, it has other advantages like only downloading a single shared copy of dependencies acquired with FetchContent.

Right now (at least using the version available for Ubuntu Jammy via apt or the newer one via snap), if you point it at an existing project using Ninja Multi-Config, it'll behave as if it's working, but if you try and build the project, instead of letting you pick the configuration, it'll just build whichever configuration(s) are set as the default via `CMAKE_DEFAULT_BUILD_TYPE`/`CMAKE_DEFAULT_CONFIGS`, and you need to change these variables and reconfigure. That means it's not totally unusable right now, but it could work better - right now KDE's being upstaged by both Visual Studio and VS Code on this front, but obviously VS is Windows-only and VS Code is a pain for C++ on Linux as its GDB in integration is ridiculously slow and frequently freezes, so neither are a viable alternative.

*Note: the form seems to be set up for bug reports rather than feature requests, so I apologise if I've posted this to the wrong place.*
Comment 1 krizdjali+kdebugs 2024-03-07 23:18:57 UTC
Something else worth noting is that the CMAKE_DEFAULT_BUILD_TYPE workaround isn't enough on its own. It means the right configuration will get built, but when debugging, it always uses the Debug configuration rather than the one from CMAKE_DEFAULT_BUILD_TYPE or CMAKE_BUILD_TYPE. I'd imagine this would be because when it inspects the compile commands CMake's exported, it just uses the first output path it sees for each target.