Add rosdep rules for two manually uploaded packages
I compiled in my PC two new packages, and manually uploaded to Artifactory.
Here the rosdep rules to resolve them.
Merge request reports
Activity
assigned to @miguel.prada and unassigned @jon.azpiazu
134 138 rc_cv_utils: 135 139 ubuntu: 136 140 xenial: [ros-kinetic-rc-cv-utils] 141 142 vtk_7.1: I'd say it is a bit heterogeneous right now (e.g.
libpcl-1.8.1
vsrobotnik_base_hw_lib
).For ROS packages at least, the rule is to use underscores in the rosdep key, and hyphens in the package name, which is what I was trying to follow.
But it is quite chaotic already, so I leave it up to you.
The issue is that we're abusing the rosdep definitions for ROS packages, which are declared differently in the official rosdistro repo, right?
I assume
libvtk
is not a ROS package, though, so I would go forvtk-7.1
as key, to be coherent with the non-ROS-package rosdep key naming convention.What do you think of separating ROS vs non-ROS (system?) dependency declarations into different files?
Looking at some examples at base.yaml, I'd go for
libtk1.7
. Rationale: there is already alibvtk
, and in some other cases the version number is not separated for the package name itself (e.g.gstreamer1.0
orlibzmq3-dev
). Also the-dev
suffix looks only useful if there is a separation between runtime and devel, which is not the case.
Building those (specially PCL) takes a lot of time (which is not critical) and also requires a lot of RAM. Some time ago, when I tried to build PCL 1.8 in the roboticsbuilder, it was not possible due to lack of RAM. That's why our version of PCL 1.8 is precompiled in my PC. I have not tried with PCL 1.9, but I assume it has not improved.
Yes, I have a simple bash script that I was planning on uploading somewhere else, in the repo that actually needs those packages. The script is simple and hardcoded , but a better alternative could be to use CMake's
ExternalProject_Add
function. I was also considering conan, but being both libraries (vtk and pcl) based on CMake, it looks much simpler to use theExternalProject_Add
approach.Not sure
ExternalProject_Add
is such a good idea, because then that repo won't be able to build in the CI environment either, will it? Or am I not getting your point right?If you have a script to build/upload those binaries I would just store them e.g. in the common_config repo, as if they were automatically built by the weekly scheduled job. Even if they really aren't. That way if the coronavirus gets to you, we can still update the packages if something goes wrong with artifactory.
That way if the coronavirus gets to you, we can still update the packages if something goes wrong with artifactory.
That was my point: if coronavirus gets me, and you have only the
.deb
you won't be able to update / make changes.If I store the recipe using e.g.
ExternalProject_Add
, it is much easier to maintain.If I store the recipe using e.g.
ExternalProject_Add
, it is much easier to maintain.I think the misunderstanding here may be coming from where that recipe is stored. I understood that you were suggesting directly pulling them with
ExternalProject_Add
from the package that requires them, and my comment was with respect to this assumption, which I think may not be right.
The reason to add those packages was because they are required by noether. But finally I was not able to make it run, and then other priorities came. We might retake this in the near future, but for the moment I will just close the issue.
In general, and following with the discussion above, it might be interesting to have a place to store recipes to build binaries to be stored in our Artifactory repository.
Edited by Jon AzpiazuIn general, and following with the discussion above, it might be interesting to have a place to store recipes to build binaries to be stored in our Artifactory repository.
Isn't that somehow what's available in the common_config repo? Recipes you used locally for VTK could also be added there, even if not used from the CI pipelines, so that anyone can reproduce if they wish.
Or are you suggesting to set up a different repository just for the recipes?
Or are you suggesting to set up a different repository just for the recipes?
I am not suggestion anything yet ;-)
Isn't that somehow what's available in the common_config repo?
That could be the place, but I have not stored there the recipes for other packages in Artifactory, e.g. PCL. Might be a solution, but taking into account that i) we would be mixing recipes that are executed by the CI and recipes that are not; and ii) storing the recipes as simple bash scripts or similar, does not guarantee reproducibility