Migration Guide for CLion/AppCode Plugins for the 2020.3 Release
This post is intended for CLion plugin authors. It explains what has changed during the 2020.3 release cycle and how you need to adjust your plugin. While CLion doesn’t provide any public plugin API for C/C++-related subsystems, a number of great plugins have been made using the limited API available. We’re very grateful to the authors for their efforts.
If you have an idea about building a plugin for CLion or any other IntelliJ-based IDEs, please refer to the documentation, which will be updated shortly to reflect the contents of this post. You’ll find useful advice as well as a few sample plugins that will help you get started.
What has changed
Previously, CLion (and AppCode) had all its code in the “core IDE”, or “platform” (which can be thought of as the root of the plugin dependency tree). This was inconvenient for various reasons, mostly related to internal CLion development; for example, it made it harder for us to share code between CLion and other JetBrains IDEs.
To address these drawbacks, we’ve moved some code from the “core IDE” to newly introduced bundled plugins –
com.intellij.clion and a bunch of other plugins it depends on. There’s a more detailed list of the bundled plugins at the end of this post.
What does this mean for you as a plugin developer?
First, the good news. You probably have a
<depends>com.intellij.modules.clion</depends> line somewhere in your plugin.xml. If you don’t have one, you’re probably not using any CLion-specific classes and are therefore not affected by this change. This would work as a dependency on the new “CLion” plugin, as this module is now defined by
com.intellij.clion. We tried not to move classes to different packages here, so your existing plugins should stay backward-compatible.
The bad news is that source compatibility is broken – your plugin can’t be rebuilt as-is anymore. To fix this, the
intellij.plugins attribute of your project should contain the IDs of all plugins you depend on.
How can you fix your build?
You should be able to build your plugin after you change your
intellij task to something like
If your plugin is based on the IntelliJ Plugin Template, you might have to use the
platformPlugins property from the
gradle.properties file instead.
What about AppCode?
For AppCode, the situation is similar – just replace
appcode everywhere in the text above.
If you’re developing a plugin from scratch or you don’t care about binary compatibility with pre-2020.3 versions, you can start depending on a plugin directly with
<depends>com.intellij.clion</depends>, which is the conventional way.
You might choose to depend on a more general plugin (i.e. to have your plugin work in CLion and AppCode at the same time), but if so, please note that class layout across the plugins might change in the future.
Here is a list of plugin IDs and the classes/subsystems they cover:
com.intellij.cidr.base– native debugger integration for CLion/AppCode, utility classes, C/C++ project model/workspace support (OCWorkspace, CidrWorkspace, etc), C/C++ build and run support, etc.
com.intellij.cidr.lang– C, C++, Objective-C/C++ language PSI Model, Swift/Objective-C Interaction, Inspections, Intentions, Completion, Refactoring, and Test Framework.
com.intellij.clion– CMake, Profiler, Embedded Development, Remote Development, Remote Debug, and Disassembly.
com.intellij.swift– everything related to Swift language support.
com.intellij.appcode– Xcode project model, CocoaPods, Core Data Objects, Device & Simulator support.
We’re sorry that this guide is being released after the fact and not alongside the actual change. While CLion and AppCode do not provide any guarantees about their public APIs, we’ll do our best to learn from this and handle these kinds of breaking changes better next time. Thank you for your understanding.
Your CLion team
The Drive to Develop
Subscribe to Blog updates
AI Assistant Insights: Writing C++ Code With the Power of AI in CLion!
AI Assistant in CLion can generate whole code snippets for you. It uses the project context to create relevant function calls and C++ statements.
Striving For Better C++ Code, Part II: Function Summaries to Speed Up the Data Flow Analysis
This is the second blog post in the series dedicated to Data Flow Analysis (DFA) and its implementation in CLion. Read the first part here: Striving For Better C++ Code, Part I: Data Flow Analysis Basics Striving For Better C++ Code, Part II: Function Summaries to Speed Up the Data Flow Analysi…
Striving For Better C++ Code, Part I: Data Flow Analysis Basics
CLion comes with a built-in data flow analyzer, which runs constantly when you are writing your code and helps improve your code’s quality. It can reveal various code problems that might later lead to runtime issues, security breaches, and other vulnerabilities. Examples of these useful checks are c…