search

Noam-Dori / ros-integrate

Extends IntelliJ-Based IDEs with ROS specific development tools
Apache License 2.0
22 stars 3 forks source link

Clion/CMakeLanguage detection not working in recent clion versions #82

Closed maciejmatuszak closed 1 year ago

maciejmatuszak commented 1 year ago

Describe the bug First, this relate the work in progress "f-cmake" branch and CMake language implementation

Trying to use it with latest Clion is failing with:

...
Caused by: com.intellij.diagnostic.ImplementationConflictException: Language with ID 'CMake' is already registered: class ros.integrate.cmake.lang.CMakeLanguage. Conflicting plugins: [com.intellij.clion, ros-integrate]

This is caused by failure in CMakeClasses.checkCLion(), that relies on finding the "com.jetbrains.cmake.CMakeLanguage" class. That class is now part of plugin and loaded after ros.integrate plugin hence it can not find it. see the discussion here

The suggested solution is to use optional dependency in plugin.xml:

`<depends optional="true" config-file="">

with runtime check for the plugin like this:

    static boolean checkCLion() {
        return PluginManagerCore.getPlugin(PluginId.getId("com.intellij.clion")) != null;
    }

The way to introduce optional dependency without config-file has changed as well See here: The proposed solution: <depends optional="true" config-file="">com.intellij.clion</depends> will no longer works. I think it needs dummy config-file or omit the param all together: <depends optional="true" >com.intellij.clion</depends> This will be red in IntelliJ as the config-file arg is mandatory, but it works at runtime. Maybe the entire CMakeExtensions.xml can be included that way?

Testing it bit more I notice that just by adding the dependency on the plugin causes it to be loaded early and the com.jetbrains.cmake.CMakeLanguage class can be found again. So the runtime check can stay the same.

Hope this helps.

Noam-Dori commented 1 year ago

Hi @maciejmatuszak, First, thank you for the insights, it should make the CLion part of the ROS-CMake integration much faster to fully implement.

To be fair, right now even with plugin registration working correctly, nothing would work properly as the "plugin invariant" CMake adapters do not implement their CLion counterparts. Issue #76 is all about that

I think the proposed tag is a good idea, as I would want to add C++ specific integrations (for example, jumping to message definitions from C++ code using a gutter icon). I also think the method you proposed is better than the current approach since its more robust to class name changes and deprecations. However, the big issue with the how most of the plugin components in CMakeExtensions.xml and in CMakeClasses.addHomeDependencies() is that they need to be applied when there is no CLion, hence why they need to be outside the depend tag. It would be very nice if there was a "depend unless" sort of tag, but to my knowledge, there is nothing of the sort.

Cheers!

maciejmatuszak commented 1 year ago

Got your branch working in latest CLion, I did not check backward versions though... https://github.com/Noam-Dori/ros-integrate/pull/83