CMake needs cleaning, it's almost unreadable

[Hoog-V]

CMake needs cleaning up

[traversaro]

• Eventually the developers abandoned this project, but the Robostack ROS project uses this still as their main tool with Vinca (recipe generator).

@Hoog-V Hello, (one of) RoboStack mantainers here. Just to understand, where did you get that impression (I guess some outdated docs somewhere)? We migrated to rattler-build in RoboStack/vinca#66 .

[Hoog-V]

Hi @traversaro,

Thanks! Cool that you check out these repository's btw. I now just saw that the change to rattler-build was upstreamed recently. The version of Vinca (and docs) I used was probably outdated. Nice to see, that it finally integrated. For now I changed the scripts quite a bit, due to the variables and build-requirements which were associated with this library. I will change it in the issue, as it is not correct.

[traversaro]

Great! Just FYI the latest "stable" one is https://github.com/RoboStack/vinca/releases/tag/v0.1.0, the master branch has some breaking changes due to the change of the name of the linux/unix script in RoboStack/vinca#73 (sorry, I missed it and I did not realized it was a breaking change).

By the way, I checked out the instructions in https://clfml.github.io/lowwi/usage/build_environment/ros2_pixi_build_linux_windows/#using-as-a-pixi-dependency and they are quite cool, I was not aware keep a full conda channel in a gh-pages github repo was doable. Just a fyi, unfortunately at the moment we do not have run_exports in our robostack packages, so your packages (I checked

lowwi/rattler/recipe.yaml

Lines 68 to 84 in f5a8276

	host:
	- ros-jazzy-ament-cmake
	- ros-jazzy-audio-tools
	- ros-jazzy-rosidl-default-generators
	- ros-jazzy-rclcpp
	- ros-jazzy-std-msgs
	- ros-jazzy-rclcpp
	- ros-jazzy-std-msgs
	- ros-jazzy-ament-lint-auto
	- ros-jazzy-ament-lint-common
	run:
	- ros-jazzy-audio-tools
	- ros-jazzy-rclcpp
	- ros-jazzy-std-msgs
	- ros-jazzy-rosidl-default-runtime
	- ros-jazzy-rclcpp
	- ros-jazzy-std-msgs

) may break if an ABI change gets released. The strategy that we use in robostack to handle ABI for now is the ros2-distro-mutex package, so if you want to avoid breakage you may just depend on ros2-distro-mutex 0.7.* and that should work (but you will have to manually update it once we do a full rebuild, such as RoboStack/ros-jazzy#38 .

[Hoog-V]

Wow! great tip! That will save me some headaches, later on.

Do you by any chance have a link to an up-to-date package on GitHub/GitLab that already uses rattler-build with this recipe.yaml format? It might be easier to copy that and use that as a base for my own scripts.

The private conda channel idea is just to help the research group and undergraduate students quickly prototype a robot together. This shortens the development time, as they do not have to wait for me upstreaming any of these repo's. I am still very pleased with the results and how good this works, everyday the channel automatically updates by checking the releases section of specified CLFML repo's. And pushing the packages from release section into the channel.

Eventually I want to upstream, but am very new in the ecosystem and get lost in the documentation. Still it is not completely clear to me, what I have to do to make this upstream-worthy.

I'm trying to get my research dept. at school to use ROS2 for prototyping robots. As well using Pixi on Windows, as some of the students don't like working in Linux (I don't get it really, it's great). The Robostack is amazing, and am very happy that you managed to get it working so well.

Btw, if I or anyother of the students interested in ROS can help you in anyway or form to help maintain the Robostack, let me know. We are of-course open to help out.

[traversaro]

Wow! great tip! That will save me some headaches, later on.

Actually by looking at the ros2-distro-mutex package at https://github.com/RoboStack/ros-jazzy/blob/fd6ca4f04019188068d6e66377c56e0d29459a2b/additional_recipes/ros2-distro-mutex/recipe.yaml#L39C41-L39C46 it seems that it already has the correct run_exports configured, so I guess you can just depend on it and everything should work fine out of the box (we should definitely document this on the robostack side).

[traversaro]

Do you by any chance have a link to an up-to-date package on GitHub/GitLab that already uses rattler-build with this recipe.yaml format? It might be easier to copy that and use that as a base for my own scripts.

Ah, good point. I think the vast majority of conda packages built by rattler-build and updated are through the conda-forge and robostack infrastructure, that may be a bit complex as a starting point.

Other alternatives you can use I think are:

• In my institution we also package some packages with rattler-build and upload them on the robotology channel on both anaconda.org and prefix.dev, you can find our scripts at https://github.com/robotology/robotology-superbuild/blob/master/doc/developers-faqs.md#how-often-are-conda-binary-packages-generated and https://github.com/robotology/robotology-superbuild/blob/master/.github/workflows/generate-conda-packages.yaml, but also there the workflow is not super-simple (the rattler-build recipes are generated by a python script starting from the metadata extracted by CMake-based superbuild.
• prefix.dev may have more examples, for example in https://github.com/prefix-dev/package-incubator, https://github.com/wolfv/rust-forge, https://github.com/wolfv/julia-forge and https://github.com/wolfv/r-forge .
• You can ask to pixi/rattler-build community in the prefix.dev's discord: https://discord.gg/kKV8ZxyzY4 . That is also what we use for coordinating most of robostack development.

The private conda channel idea is just to help the research group and undergraduate students quickly prototype a robot together. This shortens the development time, as they do not have to wait for me upstreaming any of these repo's. I am still very pleased with the results and how good this works, everyday the channel automatically updates by checking the releases section of specified CLFML repo's. And pushing the packages from release section into the channel.

Eventually I want to upstream, but am very new in the ecosystem and get lost in the documentation. Still it is not completely clear to me, what I have to do to make this upstream-worthy.

If you want to quickly re-release ROS-based packages, I guess at the moment neither the official ROS buildfarm nor robostack are appropriate, as at the moment we are quite slow on both sides on making updates on new packages (called "sync" in the official ROS build farm or "full rebuild" on robostack). So a dedicated channel make a lot of sense for that.

I'm trying to get my research dept. at school to use ROS2 for prototyping robots. As well using Pixi on Windows, as some of the students don't like working in Linux (I don't get it really, it's great). The Robostack is amazing, and am very happy that you managed to get it working so well.

Thanks for the kind words! fyi @Tobias-Fischer @wolfv @ruben-arts

Btw, if I or anyother of the students interested in ROS can help you in anyway or form to help maintain the Robostack, let me know. We are of-course open to help out.

Sure, that would be great.

We have a few issues tagged good first issue or help needed in the robostack org, see:

• https://github.com/search?q=org%3Arobostack+is%3Aissue+is%3Aopen+label%3A%22help+wanted%22&type=issues
• https://github.com/search?q=org%3Arobostack+is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22&type=issues

However, if you are interested in contributing, in my experience the easiest option to understand the overall infrastructure is to find a problem that you are facing yourself in your work related to something missing in robostack (for example, a missing package) and work on fixing that problem. In that way is easier to have motivation, as you immediately see the gain for you.

[Hoog-V]

Thanks!