How-To's Tips & Tricks

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

intellij {
    setPlugins("com.intellij.clion", "com.intellij.cidr.base")

If your plugin is based on the IntelliJ Plugin Template, you might have to use the platformPlugins property from the file instead.

What about AppCode?

For AppCode, the situation is similar – just replace clion with 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.

In summary

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

image description