# KDevelop is the KDE IDE where the platform is the plugin API

> The KDE/kdevelop repository holds the KDevelop IDE, the KDevelop Platform and most of the plugins, and its interesting property for a plugin author is that kdevplatform is a general purpose project and debugging framework rather than IDE internals. The cost is that it is a large KDE application, it publishes no GitHub releases, and its build pulls in whatever optional dependencies it can find.

**KDE/kdevelop** — Cross-platform IDE for C, C++, Python, QML/JavaScript and PHP

- Repository: https://github.com/KDE/kdevelop
- Website: https://invent.kde.org/kdevelop/kdevelop
- Stars: 596 · Forks: 109
- Language: C++
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kde-kdevelop

## The repository ships the IDE and its platform together

The repository contains the source code for the KDevelop IDE, and it also includes KDevelop Platform, kdevplatform, and most of the plugins. Other KDevelop plugins can be found in the KDevelop Group on the KDE GitLab instance.

That single sentence describes the architecture more accurately than a feature list would. The IDE and the platform that plugin authors program against live in the same repository, under the top level kdevplatform directory alongside app, plugins, share, cmake and doc. The plugins directory is where the language support, the debugger back ends and the project type handlers live, and the README notes that some plugins are not here at all but in the wider group on the KDE GitLab instance.

The project is described as a cross platform IDE for C, C++, Python, QML, JavaScript and PHP, and the primary language is C++. The homepage is on the KDE Invent instance rather than on GitHub, which is the norm for KDE projects, and the bug tracker is on bugs.kde.org.

The licence is recorded as a custom one that GitHub cannot classify, with the terms in the LICENSE file and a LICENSES directory at the top level, alongside a COPYING.DOC file for the documentation. Since the licence metadata is not machine readable here, the LICENSE file is what governs, and it is worth reading before you build a plugin on top of it.

## The build is CMake, and it takes what it finds

KDevelop is built the same way as most KDE projects, using CMake to set up a build directory and the build options, and the detailed instructions live in the KDE community wiki rather than in the repository. The README is explicit that the project has no install instructions of its own, so the compile guidance is the wiki page on compiling KDevelop v5.

The interesting part of the build is the optional dependency policy, and the README explains it plainly. Most of KDevelop's optional dependencies are opportunistic under the assumption that the build should always use all available functionality, as well as the most recent version.

In practice that means your build result depends on what happens to be installed on the machine. A newer library gets picked up, and a feature you did not ask for may be compiled in.

CMake has a lesser known feature to control which of such dependencies is used, and the README gives the Subversion plugin as the example. To skip building that plugin, the flag is -DCMAKE_DISABLE_FIND_PACKAGE_SubversionLibrary=ON. The same mechanism applies to every other optional package, which means a reproducible build is possible but has to be constructed deliberately, one dependency at a time.

For a team that cares about what ends up in the binary, that is a real cost, and it is the cost that comes with a project that treats the presence of a library as a feature request in itself.

## kdevplatform is a framework, not an IDE internal

The reason a plugin author would care about this repository is kdevplatform, and the description in the README is deliberately narrow: this repository also includes KDevelop Platform, kdevplatform, and most of the plugins.

The distinction that matters is that kdevplatform is a general purpose platform, not the private inside of the IDE. A plugin written against it does not reach into KDevelop's widgets and does not depend on the IDE's internal call structure; it targets a published interface, and the IDE is one consumer of that interface among others.

The top level layout supports that reading. There is a cmake directory with the framework's own build logic, a KDevelopConfig.cmake.in file that suggests the platform exports a CMake package config, and a share directory that would hold the shared UI resources a plugin can rely on. The app directory is the IDE proper, separate from the platform, and the plugins directory sits alongside both.

The documentation for a plugin author is not in this repository, though. The user documentation lives on userbase.kde.org under the KDevelop5 manual, and the developer entry point is the contribute page at kdevelop.org, which is a separate site from the code host. That split is normal for KDE, and it means the repository gives you the source while the API contract is documented elsewhere.

## The packaging targets are many, and none of them are GitHub releases

The repository tells a story about how this project is distributed.

At the top level there is an appimage directory, a snapcraft.yaml, and release-scripts, and there is ExtraDesktop.sh and the org.kde.kdevelop.appdata.xml file for desktop integration. A .gitlab-ci.yml and a .kde-ci.yml sit alongside developer-scripts, format_sources and a .krazy directory, which is the KDE code style checker. The .clang-format and format.config.uncrustify files cover the C++ and the shell sources respectively, and .kateconfig and .kateproject indicate the project is itself edited in Kate, the KDE text editor.

The AppImage and the Snap packaging are the distribution channels you will recognise, and both are built from this repository rather than published as tagged artefacts.

The releases story is the part to note. The repository publishes no GitHub releases, and the last push was on 2026-10-14. KDE projects are typically versioned and shipped by their own release process on the KDE infrastructure rather than by GitHub tags, so an absence of GitHub releases is normal here and not a sign of a dormant project. It does mean you cannot point a CI job at a release artefact in this repository, and the KDevelop version you get from a distribution package comes from that distribution's build of the KDE release, not from anything in this repository.

## Bug tracking still spans two systems

The Development Infrastructure section lists three places, and the third one is annotated.

The bug tracker is on bugs.kde.org with a pre-filtered list covering the unconfirmed, confirmed, assigned and reopened states for the kdevelop and kdevplatform products. The KDE GitLab instance handles code review as well as hosting and other collaboration tasks, with the merge requests link pointing at the kdevelop group. The third entry is Phabricator, described as a task tracker until this functionality is migrated to GitLab.

So a contributor is expected to work across two systems for one task, because the tracker has not yet been consolidated. That is a small friction, but it is the kind of friction that tells you something real about a project: the code moves to GitLab, the issue history stays where it is until someone migrates it.

The contribute guidance is likewise a separate page on kdevelop.org rather than a file in the repository, and the README says to read through it before contributing.

## Where KDevelop is the wrong tool

Four situations argue against it.

The first is a project that wants a light editor. KDevelop is a full IDE with a platform, a debugger integration, a project model and a plugin set. A developer whose actual need is syntax highlighting and a language server is paying for a lot of machinery they will not use, and an editor with a language server mode is a better fit for that.

The second is a language without a plugin you want. The description names C, C++, Python, QML, JavaScript and PHP, and each of those is supported by a plugin. Supporting a language in KDevelop means writing or using a plugin that implements the platform's project and parsing interfaces, which is a much larger commitment than adding a language server to an editor. If your language is not in that list and nobody has written the plugin, KDevelop is not extensible into your project by configuration.

The third is a build that has to be reproducible. The opportunistic dependency policy means the same source tree produces different binaries on different machines, and pinning that down means writing a set of CMake disable flags. Tooling that treats dependencies as fixed, such as a Nix flake or a container image with a locked package set, sidesteps the problem entirely.

The fourth is a team that wants a mainstream support path. KDevelop is a KDE project with a community around it, not a product with a support contract, and the documentation is spread across a wiki, a userbase manual, a separate contribute site and a bug tracker. The alternative worth naming is Qt Creator, which comes from the same Qt world, integrates with the same CMake and Qt tooling, and has a smaller scope because it does not try to be a general platform. For most C++ and QML work, Qt Creator covers the same ground with less to configure, and it is a better default precisely because it makes fewer demands on the build.

## Conclusion

KDevelop fits a C++ or QML developer working inside the KDE ecosystem who wants a debugger integrated with a CMake project model, and it fits a plugin author who wants to target a documented platform API rather than patch an IDE. It is the wrong choice for a team that wants a lightweight editor with a language server, and it is the wrong choice if your build has to be reproducible, because the build treats optional dependencies as opportunistic and picks up whatever versions it finds unless each one is disabled by hand. Before adopting it, check three things: that your language has a plugin you actually want rather than one you have to write, that the optional dependencies your build will pick up are the ones you intend, and that the plugin API you target is kdevplatform, since the repository also includes the IDE itself and the two are versioned together.

## FAQ

### What languages does KDevelop support?

KDevelop is described as a cross platform IDE for C, C++, Python, QML, JavaScript and PHP. Support for each language comes from a plugin, and the repository includes most of those plugins, with others available in the KDevelop Group on the KDE GitLab instance.

### How do I build KDevelop from source?

It is built the same way as most KDE projects, using CMake to set up a build directory and the build options. The README does not contain the instructions itself and refers to the KDE community wiki page on compiling KDevelop v5.

### How do I skip an optional dependency when building KDevelop?

CMake has a feature to control which optional packages are used, and the README gives the Subversion plugin as the example: -DCMAKE_DISABLE_FIND_PACKAGE_SubversionLibrary=ON skips building that plugin. The same mechanism applies to the other optional dependencies.

### What is kdevplatform and why is it in the KDevelop repository?

KDevelop Platform, kdevplatform, is the platform layer that plugins program against, and the repository includes it alongside the IDE and most of the plugins. It is a general purpose project and debugging framework rather than IDE internals, which is what makes the plugin API something a plugin author can target.

### Where do I report a KDevelop bug?

The bug tracker is on bugs.kde.org, with a pre-filtered list for the kdevelop and kdevplatform products. Code review and hosting happen on the KDE GitLab instance, and Phabricator is still used as a task tracker until that functionality is migrated to GitLab.

## Sources

- [Issues](https://github.com/KDE/kdevelop/issues)
- [KDE/kdevelop on GitHub](https://github.com/KDE/kdevelop)
- [Project website](https://invent.kde.org/kdevelop/kdevelop)
- [README](https://github.com/KDE/kdevelop/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kde-kdevelop