CMake integration - external plugin or built-in support?

[Noam-Dori]

CMake is a major component of ROS projects. It is responsible for defining C++ executables, package decelaration, as well as linking everything together, especially with catkin_make in ROS1. Even in ROS2, packages still use CMake as a main tool.

Therefore, it is imperative that a proper ROS plugin would be able to use CMakeLists files to infer data, as well as automatically edit them. At the very least, it should be able to properly highlight them.

The current ability of JetBrains IDEs to interpret CMake depends on the IDE in question:

• CLion, which makes up about 53.6% of this plugin's userbase, has CMake support which is used mainly to make C++ highlighting and inspections work. The highlighting and overall support is very basic.
• PyCharm (Community, Professional, Education), which makes up about 41.9% of the plugin's userbase, has no CMake support of any kind, and requires a 3rd-party plugin if we wish to do anything with CMake files.
• Other IDEs (Chief among them is IntelliJ IDEA), that make up about 4.4% of the userbase, stand in a similar situation as PyCharm.

A good solution to the problem should be able to introduce CMake files without depending on CLion original CMake plugin but without interrupting its C++ functions.

There are two (maybe three) possible solutions:

1. Use CMake Simple Highlighter, and extend it. This is a plugin dedicated specifically to highlighting CMake files. The plugin also claims to not interrupt CLion. However, the extension it provides is highlighting for all IDEs, as its "smarter" features were split into a paid extension, meaning implementing smarter features could potentially interfere with the paid plugin.
2. Implement CMake support on my own. This is the fallback option if the existing plugin has critical issues.
3. Attempt to port CLion's CMake plugin into other IDEs. I do not know if this is possible, but it could be worthwhile.

I have never used the plugin, not to mention the paid variant. We get the following questions:

• Do people who download this plugin use the CMake plugin? Do they have any issues with it that this plugin could address?
• Do those same people use the paid variant? Knowing this could indicate how careful this plugin should be not interrupting the paid variant's features (or maybe offer an option to toggle features on/off)?
• Is the CMake plugin truly compatible with all of CLion's functions? If not, what does it interfere with?

Plugin Version CMake integration is the main point of the next version - 0.1.7

[Doomerdinger]

I have used the CMake highlighter plugin in the past - only the free version - and I uninstalled it at some point. I can't remember why, I may have just not found the free version terribly useful. I primarily use CLion, and it has some rudimentary highlighting that I may have decided was sufficient. I'll install the plugin and let you know of any quirks I find.

[Noam-Dori]

For the past several months, I have been testing integration of the CMake highlighter plugin into this plugin. From my experience with the plugin, both as a general user and as a developer:

1. the base plugin does one and one thing only: highlight CMake files and build a PSI tree for them (PSI tree in this case referring to how the words and symbols in the file are structured).
2. In order to coexist with CLion, the plugin turns its language component off when installed on CLion. In CLion, it uses the existing CMake code and builds on it. This means there is work put into creating adapters.
3. While the CMake plugin does its job, it has quite a bit of code that has been deprecated for a long time. It is also missing a lot of API I as a developer could really use, like searching for a named command in a file, or in general any utility functions regarding CMake files. It does offer CMake variable definition to use lookup from the code, though it is exposed to the user in the plus version.
4. The real nail in the coffin is the following piece of code:

   @NotNull
   public static PsiReference[] getReferences(PsiElement o) {
     if (!CMakeComponent.isCMakePlusActive) return PsiReference.EMPTY_ARRAY;
     List<TextRange> innerVars = getInnerVars(o);
     if (innerVars.isEmpty()) return PsiReference.EMPTY_ARRAY;
     PsiReference[] result = new PsiReference[innerVars.size()];
     for (int i=0; i<innerVars.size(); i++) {
       TextRange innerVar = innerVars.get(i);
       result[i] = new MyPsiPolyVariantReferenceBase<>(o, innerVar);
     }
     return result;
   }

   This piece of code is the plugin's way to allow things like command arguments to link to other objects throughout the project. These references are used a lot in IntelliJ, from completion to rename refactoring to Ctrl+Click. For example, they are used in .msg files to allow users to navigate from a used message to the file that defines it. In here, the kind of references CMake objects can provide is set in stone. It can only give one specific type of references, and only if the premium version is installed. The function should look like this:

   @NotNull
   public PsiReference[] getReferences(PsiElement o) {
        return ReferenceProvidersRegistry.getReferencesFromProviders(o);
   }

   With this implementation other plugins can add additional work to link up CMake things with things like packages, message files, launch files etc. so that the IDE can really help out with things (for example, creating a new message file will require no additional user work since the plugin adds all of the boilerplate code)

5. why not copy the code and modify this part? First, this can damage other components in the plugin. Second, the current source code is not the most updated code so there will be a lot of catch-up work to do. Last, the code is under the GPLv3 license, which is more strict than this code (Apache 2.0). If I copy GPL code into this repository, I must turn it into GPL, which I don't want to do since it can harm the users.

Issues 4+5 pose a fatal blow to any hope of integrating the plugin into ROS. Therefore, this plugin must implement its own CMake language tool that will use the basic design concepts that went into the CMake plugin.