ros / class_loader

ROS-independent library for dynamic class (i.e. plugin) introspection and loading from runtime libraries
http://www.ros.org/wiki/class_loader
35 stars 95 forks source link

Could not find a package configuration file provided by "ament_cmake" with any of the following names: #125

Closed bionade24 closed 5 years ago

bionade24 commented 5 years ago

Latest relase of this package, ros-melodic installation.

CMake Warning at CMakeLists.txt:16 (find_package):
  By not providing "Findament_cmake.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "ament_cmake", but CMake did not find one.

  Could not find a package configuration file provided by "ament_cmake" with
  any of the following names:

    ament_cmakeConfig.cmake
    ament_cmake-config.cmake

  Add the installation prefix of "ament_cmake" to CMAKE_PREFIX_PATH or set
  "ament_cmake_DIR" to a directory containing one of the above files.  If
  "ament_cmake" provides a separate development package or SDK, be sure it
  has been installed.

CMake Error at CMakeLists.txt:19 (find_package):
  By not providing "Findconsole_bridge_vendor.cmake" in CMAKE_MODULE_PATH
  this project has asked CMake to find a package configuration file provided
  by "console_bridge_vendor", but CMake did not find one.

  Could not find a package configuration file provided by
  "console_bridge_vendor" with any of the following names:

    console_bridge_vendorConfig.cmake
    console_bridge_vendor-config.cmake

  Add the installation prefix of "console_bridge_vendor" to CMAKE_PREFIX_PATH
  or set "console_bridge_vendor_DIR" to a directory containing one of the
  above files.  If "console_bridge_vendor" provides a separate development
  package or SDK, be sure it has been installed.

Same issue with other package: https://github.com/ros/ros_environment/issues/15

jwhendy commented 5 years ago

How did you fix this?

bionade24 commented 5 years ago

I believe I wrote this once in a mail, that some of the packages under ROS1 github group with a 2.x release are for ROS2. So we have to choose the 1.x Releases. They're still both versions in development, at some packages you can see 1.x updates after 2.x was updated. So just stay with 1.x releases, I was just silly and believed that everything under ROS is for ROS1

jwhendy commented 5 years ago

You did say that. I just thought ROS1 = 1.x and ROS2 = 2.x for the versioning. For this package, how do you identify which is ROS1 vs. ROS2, as there is no 2.x in releases? Is it 0.x vs. 1.x?

bionade24 commented 5 years ago

Probably yes. Will try it when I'm at home.

jwhendy commented 5 years ago

Did you check on this and how to tell ROS1 vs. ROS2? Is it always the lowest major version number (e.g. 0 or 1) vs. the higher (1 or 2)?

bionade24 commented 5 years ago

I only had the case where it was the lower one, but I'll ask.

nuclearsandwich commented 5 years ago

class_loader in ROS 1 will likely always occupy the 0.x version space. Versions greater than 1.x are being used for ROS 2. There is a possibility that the class_loader codebase for ROS 1 and ROS 2 may unify in time.

When choosing class_loader releases you should check the ROS distribution you are targeting and use the same version. For example here is the class_loader entry for Melodic on the ROS index https://index.ros.org/p/class_loader/github-ros-class_loader/#melodic which specifies the currently released version 0.4.1.

bionade24 commented 5 years ago

But, e.g. pluginlib uses 1.x and 2.x releases. So it's always the lower number for ROS1, isn't it?

nuclearsandwich commented 5 years ago

But, e.g. pluginlib uses 1.x and 2.x releases. So it's always the lower number for ROS1, isn't it?

The only thing you should be relying on is what the ROS distribution reports. Any other heuristic is not guaranteed even if it may not ever be incorrect.

bionade24 commented 5 years ago

Ok. When we fetch the correc version from the API of index.ros.org, it shouldn't be a problem.