Skip to content
Snippets Groups Projects

Add rosdep rules for two manually uploaded packages

Closed Jon Azpiazu requested to merge add-packages into master
3 unresolved threads

I compiled in my PC two new packages, and manually uploaded to Artifactory.

Here the rosdep rules to resolve them.

Edited by Jon Azpiazu

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
134 138 rc_cv_utils:
135 139 ubuntu:
136 140 xenial: [ros-kinetic-rc-cv-utils]
141
142 vtk_7.1:
  • It would help avoid confusion if this was named vtk-7.1, since all existing rosdep rules use hyphens instead of underscores.

  • I'd say it is a bit heterogeneous right now (e.g. libpcl-1.8.1 vs robotnik_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 for vtk-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 a libvtk, and in some other cases the version number is not separated for the package name itself (e.g. gstreamer1.0 or libzmq3-dev). Also the -dev suffix looks only useful if there is a separation between runtime and devel, which is not the case.

  • Sounds good to me.

  • Please register or sign in to reply
    • I compiled in my PC two new packages, and manually uploaded to Artifactory.

      Any reason not to build these automatically?

    • 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.

    • I see. Do we at least have some sort of script to automate the build, even if it doesn't run on the roboticsbuilder and needs to be ran manually?

    • 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 the ExternalProject_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.

    • Please register or sign in to reply
    • Just found out this one is still open. What should be done about it? Close? Merge?

    • 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 Azpiazu
    • 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.

      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

    • I am not suggestion anything yet ;-)

      And now I'm curious... :rofl:

      i) Yes, that's definitely a problem. Though it may still be beneficial to have all recipes, even if some of them are not run automatically, right?

      ii) Better than nothing, I guess. Do you have any alternative in mind?

    • Not really a proposal, but I tend to think that using Conan might be a good idea (or similar tools like vcpkg).

    • Please register or sign in to reply
  • closed

  • Jon Azpiazu changed the description

    changed the description

  • Please register or sign in to reply
    Loading