CLion top level ROS2 Workspace CMakeLists

CMakeLists.txt

cmake_minimum_required(VERSION 3.14)
project("ROS2 Master")

# usually I put this in a separate file include("/opt/ros/_common/Colcon.cmake")
function(colcon_add_subdirectories)
  cmake_parse_arguments(PARSE_ARGV 0 "ARG" "" "BUILD_BASE;BASE_PATHS" "")

  message("search criteria: ${ARGV}")

  execute_process(COMMAND colcon list
		--paths-only
		--base-paths ${ARG_BASE_PATHS}
		--topological-order
		${ARG_UNPARSED_ARGUMENTS}
		OUTPUT_VARIABLE paths)
  string(STRIP "${paths}" paths)
  string(REPLACE "\n" ";" paths "${paths}")

  MESSAGE("colcon shows paths ${paths}")

  foreach(path IN LISTS paths)
    message("...examining ${path}")
    # if(EXISTS "${path}/CMakeLists.txt")
    execute_process(COMMAND colcon info --paths "${path}" OUTPUT_VARIABLE package_info)
    if(NOT "${package_info}" MATCHES "type:[ \t]+(cmake|ros.ament_cmake|ros.cmake)")
      message("skipping non-cmake project")
    elseif(NOT "${package_info}" MATCHES "name:[ \t]+([^ \r\n\t]*)")
      message(WARNING "could not identify package at ${path}")
    else()
      set(name "${CMAKE_MATCH_1}")
      message("...adding package ${name} from path ${path}")
      MESSAGE("package info: ${package_info}")

      get_filename_component(BUILD_PATH "${name}" ABSOLUTE BASE_DIR "${ARG_BUILD_BASE}")

      add_subdirectory("${path}" "${BUILD_PATH}")
    endif()
  endforeach()
endfunction()

colcon_add_subdirectories(
	BUILD_BASE "${PROJECT_SOURCE_DIR}/build"
	BASE_PATHS "${PROJECT_SOURCE_DIR}/src/"
	--packages-select rmw_cyclonedds_cpp performance_test
)

Any thoughts on how I could fix this if I wanted to be able to build multiple packages.

The problem here is that multiple projects are creating a target named uninstall. I'd set AMENT_CMAKE_UNINSTALL_TARGET to OFF. The uninstall target is pretty useless but I got pushback when trying to remove it in ament/ament_cmake#205.

how to support the custom package by find_pakcage api?

find_package(${custom_package} REQUIRED)

@MagicRUBICK

find_package should work the same as it usually does. Maybe clarify what you're trying to do?

Thanks this works great for building packages! I am running into problems however when I try to run a node in a debugger:

'Type support not from this implementation. Got:
Handle's typesupport identifier (rosidl_typesupport_cpp) is not supported by this library, at ./src/type_support_dispatch.hpp:111
Could not load library libsba_interfaces__rosidl_typesupport_fastrtps_cpp.so: dlopen error: libsba_interfaces__rosidl_typesupport_fastrtps_cpp.so: cannot open shared object file: No such file or directory, at ./src/shared_library.c:99, at ./src/type_support_dispatch.hpp:76
while fetching it, at ./src/subscription.cpp:117, at ./src/rcl/subscription.c:108'

with this new error message:

'invalid allocator, at ./src/rcl/subscription.c:218'

Did you add any modifications to your run/debug config?

@janklatte That looks like you might be mixing Ros installations? Notice that first line. Could your env variables configured in your clion be pointing to a binary pkg installation perhaps? The warning "type support not from this implementation" indicates this, then it looks like maybe a linker error with invalid allocator since you have a mixed implementation (if this is in fact the case).

This could be a difference in ENV variables between your CLion toolchain setup, and your debug/runtime profile ENV setup.

Perhaps start your configuration fresh. new bash with clear env, source the Ros installation you want, then see my post above with the little for loop script to pull out the ros2 variables and copy/paste into CLion again. Two place, both under toolchain setup (for compilation) and under your debug profile (runtime). Before pasting in new env vars, clear out the previous stuff, especially PATH. In Clion Env dialog clearing out the top is easy, but the System vars in the bottom list you have to scroll through and look for the bolded lines that indicate system overriden ones. Then paste into the user ones and Apply.

yes that was it thank you @guru-florida! Under my Toolchain configuration I added the setup.bash as environment file in previous attempts to get it working but forgot to remove it again. Now with just the copied environment variables in the cmake configuration it is working!

Another smaller issue I have is that the linter/intellisense doesn't find the rclcpp/rclcpp.hpp header. Other ros2 headers are found (e.g. #include "message_filters/subscriber.h" or #include "nav_msgs/msg/grid_cells.hpp"). Might be an issue with the CMakeLists.txt but in case anyone already has an idea let me know.

@janklatte That sounds very similar to the issue I reported here https://youtrack.jetbrains.com/issue/CPP-29747/Certain-ROS2-package-headers-missing-from-Intellisense-when-using-a-Docker-toolchain

Thanks so much for providing this, but I'm having a bit issue with the add_subdirectory. When I was trying to reload this file in Clion, it complained about missing targets like the following. So all I add is a simple_publisher from (https://docs.ros.org/en/foxy/Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.html. I believe the top-level cmake should invoke all the functionalities from ament_cmake in the ros2 packages but it finds it hard to link the sub-targets.

  Target "simple_publisher" links to target
  "std_msgs::std_msgs__rosidl_generator_c" but the target was not found.
  Perhaps a find_package() call is missing for an IMPORTED target, or an
  ALIAS target is missing?

@Catially I have not been actively working with ROS for some time, so I unfortunately can’t help

@Catially This is a pretty standard error for when GCC isn't aware of where the Ros2 core libraries are. This script will find your source code but it doesnt add the ros2 core libs to gcc builds. Through Jetbrains File | Settings | Build menu you can manually add libs or the easiest way is to source the ros core setup.py then launch clion from the same shell. Thus ros core libs will already be in the build env paths.

Nice script for debugging in CLion!

But there's a tiny defect, seems with the CMakeLists.txt I cannot directly use colcon build anymore, any way to compatable them ?

You probably shouldn't be using this script with colcon. It would mean colcon would assume this script is a package on it's own and include your subprojects in it. Perhaps you could put this script in a top level directory and use it to open with clion, then use colcon on the inner directory with all the subprojects when you want to compile as packages.

THANKS

You can also use the --base-paths src/* colcon argument from your top-level directory in case you have all your ros2 components in a child directory (e.g. src).