demmeln's profile - activity

This is a bit of a follow up on the answer to this questions: http://answers.ros.org/question/108916/openni_launch-rosdep-on-os-x/

So assuming I have build and installed ROS (e.g. the desktop-full variant), I'm woundering how to best maintain my installation, meaning adding additional packages (which on ubuntu I would install via apt-get) and updating the whole installation to current releases (staying on the same distro, hydro in my case).

Is it possible and recommended to install to the same install space (e.g. /opt/ros/hydro) from different workspaces? E.g. I would like to add additional packages like suggested in the answer linked above. Can I build them in a freshly created workspace and install to /opt/ros/hydro? Should I instead extend my workspace with which I build the original packages installed to /opt/ros/hydro?

How would I go about upgrading my packages to the latest releases? Can I use my existing workspace and update the .rosinstall file to the latest released versions? What is the best practice here?

Makes sense. So I guess the answer is, its possible with colcon, e.g. with a colcon.pkg file (instead of package.xml) in

Wait, I think I misunderstood how the .meta files work. It should be possible with those (either with name or path).

Wait, if you use ExternalProject, you can specify any options you want in the wrapper project, no? Or are you asking how

So you can specify this in the source of the package and you can customize the defaults for that package (compared to a

Doesn't bloom allow you to include "patch files" that can tweak the defaults of options in the CMakeLists.txt as needed?

If you building your workspace with catkin_tools, you can specify cmake args (--cmake-args I believe), but the caveat is

Looks for the log like it does not run make run_tests for pure cmake packages. But it does look like it runs 02:12:27

Thanks. For the record, I've had success with passing additionally -DCMAKE_CXX_STANDARD=14 in catkin config to compile l

Thanks for confirming the current state. Just for the record, an alternative to changing package format again would mayb

@William @Dirk Thomas, friendly ping about the issue concerning different build_type for mixed catkin / ament packages (

@Willaim @Dirk Thomas, friendly ping about the issue concerning different build_type for mixed catkin / ament packages (

@Dirk Thomas, your answer is insightful, but it is still a bit unclear to me what is the "recommended" approach for ROS

@William @Dirk Thomas, is there a solution in sight for the issue concerning build_type for a mixed ros1 / ros2 package?

@William @DirkThomas, is there a solution in sight for the issue concerning build_type for a mixed ros1 / ros2 package?

@William @dirk-thomas, is there a solution in sight for the issue concerning build_type for a mixed ros1 / ros2 package?

Btw, how do we deal with the different build_type for ros 1 and ros 2 for regular catkin / ament packages? As @nuclearsa

Just saw your third comment. Posted the answer by accident. The example is helpful, thanks!

Ah ok. I'm still unsure about the buildtool_depend. For build_type cmake, what should it be. I have seen ament_cmake, am

Or is there an example?

Ah I see. Is there documentation for plain cmake packages with ament somewhere? For example, should you add something li

So is there a way to use this to build pure cmake packages for both ros 1 and 2 with a single package.xml? AFAICT the re

You can remove build_isolated, devel_isolated and install_isolated to wipe all generated files and start a clean build.

Not sure what causes this. genmsg should be a ROS package that you have from source in your catkin workspace. Maybe try

Yeah both answers by William are really great. It would be great to add those to the wiki, or at least some links to the answers here (anyone can edit the wiki ofc)...