Workflow for CLion and ROS

edit

Furthermore, macros like find_package(catkin REQUIRED COMPONENTS ...) are ROS-specific and thus not recognized by traditional Linux C/C++ toolchains.

find_package(..) is standard CMake functionality. The result of find_package(catkin REQUIRED COMPONENTS ...) is the definition of a nr of CMake variables (catkin_LIBRARIES, catkin_INCLUDE_DIRS, etc). A call to find_package(Boost REQUIRED COMPONENTS ..) would result in those same variables.

I'm not using CLion, so I wouldn't know whether it actually supports CMake or extracting information from it, but I would think that if an IDE can deal with CMake, it should be able to deal with Catkin (which is basically CMake).

My bad, find_package is a standard CMake part indeed. Things like add_action_files and catkin_add_gtest can be considered standard CMake macros as well, but details of their definition are ROS-specific and some additional work has to be done by IDE to fully support them, say, automate their editing based on source code changes. On the contrast, addition of new header files CLion proposes valid CMake editing, while editing package.xml is not monitored by CLion in any way.

On the contrast, addition of new header files CLion proposes valid CMake editing, while editing package.xml is not monitored by CLion in any way.

well, no. Not without a plugin adding that probably.

But is that situation so different from using CLion with any other package system that relies on metadata not captured by CMakeLists.txt? The additional metadata is needed (#q217475), CMakeLists.txt does not contain it or it's hard to extract it.

Thank you for the link on CMake/package.xml differences. I agree that working with distributed metadata is hardly seen in any IDE, but again adding at least some background analysis on the connections of source files and metadata, even though distributed and probably overlapping, would make things easier from a developer's prospective. And complete (in my opinion) lack of it is what made me write my answer on the original question if there is a good workflow automation as no, not today at least.

I agree there is no automated way to handle this in CLion at the moment, so your answer is not wrong. That's also not what I was trying to say.

I was more triggered by this part:

ROS is still very immature when it comes to dependency management and building: you have to manually edit package.xml and CMakeLists.txt for rather simple operations like adding messages.

If you have any ideas on how to automate this then there would be more than enough interest in that.

A complicating factor is that CMakeLists.txt can be arbitrarily complex, so writing a tool that can update a CMakeLists.txt without destroying what is already there is not trivial. So far no-one has bothered to do that, so that's why manual updating is still preferred/used.

If you know of a way to address this, please suggest one.