Closed DasRoteSkelett closed 1 month ago
Picking up the discussion of #1118: Thanks for the review. I basically adapted your changes @robwoolley , with the little twist of allowing to set the Python install path externally, which made it upstreamable (which I already did here. Also, I opted for the even more radical approach of deleting the detection of python3-kdl in the -vendor package.
Regarding the versions: orocos-kdl is not a ROS package as such. My opinion is, that we should be able to take the latest version (and in fact, we have been using it with noetic and did not have any issues) without any complications or obligations, like we do with all other libraries from poky or meta-openembedded.
Thanks for revising the PR and for the comment above. I agree with your comment that orocos-kdl isn't a ROS package and thus we should be able to take the latest version. Glad to hear that you have been using it with noetic without issue. I will do a build test for the supported ROS distros.
Merged into master-next: https://github.com/ros/meta-ros/commit/17fe23d41d99d922d5f82b7e9241feb3bf6d21fa https://github.com/ros/meta-ros/commit/43a2537756ddb16e664e3fb0179f4083e9f50dc9
I will do a build test across all the supported ROS distros before merging to master.
Tested against Rolling, Iron, and Humble for Styhead (ie master). Merged into "master" branch.
The recipe was failing with
This comes from the patch that will be dependent on the hashes of the package, therefore this approach is prone to fail on every refresh of this package.
The alternative approach is to introduce a yocto recipe for orocos-kdl, which basically makes any appends to orocos-kdl-vendor obsolete.
orocos-kdl can be used in other distros (humble, noetic) as well, so I placed it into ros-common layer.