Bug 482745

Summary:	Support Ninja Multi-Config CMake generator
Product:	[Applications] kdevelop	Reporter:	krizdjali+kdebugs
Component:	Build tools: CMake	Assignee:	kdevelop-bugs-null
Status:	REPORTED ---
Severity:	normal
Priority:	NOR
Version First Reported In:	5.7.211203
Target Milestone:	---
Platform:	Other
OS:	All
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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.