ros-integrate
ros-integrate copied to clipboard
Discover build configurations in non `catkin_make` environments
Feature: Discover package build configurations in the loaded workspace without needing to write a fake top level cmakelists.
Background
https://github.com/Noam-Dori/ros-integrate/issues/52#issuecomment-716621973
In modern ros workspaces, catkin_make
is not used so there is no generated workspace level cmakelists. To get clion parsing to work properly, we currently have to create a fake top level cmakelists that calls add_subdirectory
for every single source package and metapackage in the workspace. Without it, none of the clion features work properly.
Details I propose that the plugin detect when a ros workspace doesn't have a top level cmakelists and somehow provide the clion backend with the data required to detect all the build configurations. This should be functionally equivalent to to manually creating a fake cmakelists file, but im not sure if maybe theres a way to do this in a way that's automaticc and behind the scenes(ie. doesn't actually generate a fake file in the workspace root, but somehow provides the equivalent info to the ide).
Hi @wmmc88 ,
While issue #56 took care of recognizing the top level directory, and the plugin is capable of detecting (and locating) all ROS packages in the workspace, implementing this feature requires CLion specific integration (specifically, with its CMake interface). I do plan on implementing this, but the plugin doesn't know how to work with CLion specific features yet.
However, the plugin might be able to assist in making the fake top level CMakeLists file by linking the list of ROS packages to a CMake file template. Would that help?
Would it automatically maintain that file? (ie. If new packages were added from cli, would it detect and update the fake top level cmakelists?)
File templates only work when creating the files, once the file is created the template can no longer change the file
imo there isn't much value unless it updates itself. a template doesn't seem like an improvement over just creating that "fake" cmakelists myself since its pretty trivial