ament_vendor: Add IS_VENDORED_OUTPUT_VARIABLE_NAME argument and AMENT_VENDOR_POLICY CMake option #592
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Evolution of #552 .
This PR aim is based on our experience at RoboStack with the ament_vendor, and aims to improve the experience of downstream packagers of ROS on non-officially supported platform (being them conda/robostack, nix or similar), reducing the need of patching the vendor package to obtain the required behaviour.
In particular, a common pattern that we are experiencing is that compare to stable linux distributions, rolling releases as conda-forge have much more recent packages, so in many case we want to disable completely the vendoring in
_vendor
packages.A few examples:
zenoh_cpp_vendor
: In conda-forge, we have a build ofzenoh_cpp
that includes all the features required byrmw_zenoh
(see https://github.com/ros2/rmw_zenoh/blob/56f2688994600a176b9b26f7c2f23c00487e220c/zenoh_cpp_vendor/CMakeLists.txt#L18) and also all the default features enabled, so we want to force the use of the conda-forge version, instead of havingzenoh_cpp_vendor
builds its own limited variant ofzenoh
, that could conflict with the conda-forge' zenoh.gz-*-vendor
packages: In conda-forge, we have a build of the gz libraries that support Python bindings (differently from vendor packages, see Enable Python Bindings gazebo-tooling/gz_vendor#2) so we want to use them. However, the satisfied check in gz-math-vendor and other packages isEXACT
by default (see https://github.com/gazebo-release/gz_math_vendor/blob/51d2e68e872d2f071bdf40fe7017b9a00ddd8a19/CMakeLists.txt#L31-L37), and the check is not easily disabled by CMake arguments (just from environment variables, but that is tricky for example to set via colcon.pkg files).At the moment, we handle that with a lot of patches (see for example https://github.com/RoboStack/ros-kilted/blob/main/patch/ros-kilted-zenoh-cpp-vendor.patch, https://github.com/RoboStack/ros-kilted/blob/main/patch/ros-kilted-gz-cmake-vendor.patch, https://github.com/RoboStack/ros-kilted/blob/main/patch/ros-kilted-gz-rendering-vendor.patch and all similar patch in that directory). However, patches are typically cumbersome to maintain, as you need to frequently update them if patched project changes.
To deal with this, this PR adds the
AMENT_VENDOR_POLICY
CMake option, whose documentation is included in the code, and is reported in the following:One downside of having this option, is that now it is not anymore trivial to know if
ament_vendor
actually vendored something or not, while before it was sufficient to check if the variable passed toSATISFIED
wasTRUE
or not (see for example https://github.com/gazebo-release/gz_sim_vendor/blob/423f5eaf34d1c69735c99704c610e434e902886e/CMakeLists.txt#L90). For this reason, the PR also adds aIS_VENDORED_OUTPUT_VARIABLE_NAME
argument that pass the variable name that is populated byament_vendor
reporting if the package is actually vendored or not.For example, the
gz-vendor
packages could be modified as in the following: