Revision history [back]

No, that's not supported right now.

No, that's not supported right now.

No, that's not supported right now.

Edit:

How do you typically customise standard cmake libraries when used with ROS.

technically, I believe the answer would be: "you don't".

ROS does not do anything special in this area. It's all just CMake (edit: for CMake-based packages that is), and anything which didn't start out as a "ROS package" would be considered a system dependency.

Do I need wrap every single library I use in a "vendor" package.

No, that's not required at all.

Only if you want to support platforms/OS for which there is no binary release of your dependency and you want to be able to treat your has-to-be-built-from-source-dependency as your actual ROS packages (ie: plop it in a workspace, have it download the sources as part of the configure step, etc). AFAIK, vendor-packages should be considered a last-resort.

If possible, I personally manage system dependencies in whatever way the OS manages them. If possible, install pre-packaged binaries. If you're building from source, how would you normally do that? If you want to automate that, how would you normally do that?

For ROS 2 specifically -- which basically means: when driving your workspace build with Colcon -- you could make use of the various ways Colcon supports specifying metadata for packages / workspaces. See #q333249 for a previous Q&A about this.

But note that this is not required for a system dependency. It's a convenient bit of functionality, but regardless of how you manage your dependencies: as long as CMake can work with / find them, your ROS 2 package should be able to as well.

Is there a way to put standard cmake options in the package.xml and have them passed onto a standard cmake package at configure time?

No, that's not supported right now.

Edit:

How do you typically customise standard cmake libraries when used with ROS.

technically, I believe the answer would be: "you don't".

ROS does not do anything special in this area. It's all just CMake (edit: for CMake-based packages that is), and anything which didn't start out as a "ROS package" would be considered a system dependency.

Do I need wrap every single library I use in a "vendor" package.

No, that's not required at all.

Only if you want to support platforms/OS for which there is no binary release of your dependency and you want to be able to treat your has-to-be-built-from-source-dependency as your actual ROS packages (ie: plop it in a workspace, have it download the sources as part of the configure step, etc). etc. Similar to how CMake FetchContent works). AFAIK, vendor-packages should be considered a last-resort.

If possible, I personally manage system dependencies in whatever way the OS manages them. If possible, install pre-packaged binaries. If you're building from source, how would you normally do that? If you want to automate that, how would you normally do that?

For ROS 2 specifically -- which basically means: when driving your workspace build with Colcon -- you could make use of the various ways Colcon supports specifying metadata for packages / workspaces. See #q333249 for a previous Q&A about this.

But note that this is not required for a system dependency. It's a convenient bit of functionality, but regardless of how you manage your dependencies: as long as CMake can work with / find them, your ROS 2 package should be able to as well.

Is there a way to put standard cmake options in the package.xml and have them passed onto a standard cmake package at configure time?

No, that's not supported right now.

Edit:

How do you typically customise standard cmake libraries when used with ROS.

technically, I believe the answer would be: "you don't".

ROS does not do anything special in this area. It's all just CMake (edit: for CMake-based packages that is), and anything which didn't start out as a "ROS package" would be considered a system dependency.

Do I need wrap every single library I use in a "vendor" package.

No, that's not required at all.

Only if you want to support platforms/OS for which there is no binary release of your dependency and you want to be able to treat your has-to-be-built-from-source-dependency as your actual ROS packages (ie: plop it in a workspace, have it download the sources as part of the configure step, etc. Similar to how CMake FetchContent works). AFAIK, vendor-packages should be considered a last-resort.

If possible, I personally manage system dependencies in whatever way the OS manages them. If possible, install pre-packaged binaries. If you're building from source, how would you normally do that? If you want to automate that, how would you normally do that?

For ROS 2 specifically -- which basically means: when driving your workspace build with Colcon -- you could make use of the various ways Colcon supports specifying metadata for packages / workspaces. See #q333249 for a previous Q&A about this.

An example (from here):

{
    "name": "microcdr",
    "type": "cmake",
    "cmake-args":[
        "-DUCDR_ISOLATED_INSTALL=OFF"
    ]
}

Micro-CDR is a plain-CMake project. When the build is being driven by Colcon, it will read this colcon.pkg file and set the CMake argument included in it.

But note that this is not required for a system dependency. It's a convenient bit of functionality, but regardless of how you manage your dependencies: as long as CMake can work with / find them, your ROS 2 package should be able to as well.