ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Compartmentalised catkin_make

asked 2019-10-30 02:52:48 -0500

KenYN gravatar image

Given our large 100+ package project and a rather slow target machine, the CMake file regeneration step is painfully slow, but it is made doubly slow by a feature of CMake described here that means that any package that includes a CUDA file will force the whole project to require two configurations.

Is there any way to avoid this double reconfiguration? Or somehow build the offending packages in isolation so we can localise the rebuild?

I know we could switch to catkin build, but changing tools would be a harder sell...

edit retag flag offensive close merge delete



While changing to catkin_tools might be a hard sell, it could also significantly ease the problem you're describing. The isolated CMake environment of each package means much less time just running CMake on all packages when a single CMake file changed. What about switching to catkin_make_isolated? Less time on CMake, but more time on building. Depending on the types of changes you're regularly encountering, this could be an attractive option.

jarvisschultz gravatar image jarvisschultz  ( 2019-10-30 16:23:22 -0500 )edit

catkin_make_isolated might be an easy switch but it doesn't offer processing packages in parallel. So for larger packages it doesn't offer a good performance. Beside catkin_tools you might also want to consider trying colcon which is the build tool of choice in ROS 2 but also works for ROS 1. In terms of performance it should be similar good as catkin_tools - both support processing packages in parallel.

Dirk Thomas gravatar image Dirk Thomas  ( 2019-10-30 21:27:48 -0500 )edit

I looked at the FindCUDA.cmake file, and rewriting looks very tricky... catkin_tools looks like the best bet, although I'm having a separate problem that I'll make another post about.

KenYN gravatar image KenYN  ( 2019-10-31 02:43:42 -0500 )edit

@KenYN: workspace overlaying doesn't work for you?

gvdhoorn gravatar image gvdhoorn  ( 2019-10-31 09:03:14 -0500 )edit

@gvdhoorn Our project is under development, so the things we could class as library modules for the underlay would be few indeed, and as I understand it we'd have to build each layer separately, so I don't think the effort would be worth it.

KenYN gravatar image KenYN  ( 2019-10-31 20:33:13 -0500 )edit

Wouldn't you just put the CUDA-affected packages in the underlay? At least that is what I understood is your problem right now.

gvdhoorn gravatar image gvdhoorn  ( 2019-11-02 08:35:30 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-10-30 11:46:28 -0500

gvdhoorn gravatar image

One thing I could think of would be workspace overlaying.

See #q330040 for a recent Q&A where I discussed this.

The OP there was looking for a way to avoid rebuilding specific packages (as they never changed, but needed to be built from source). Your situation seems similar: you seek to avoid a rebuild of all packages.

Be aware though: not rebuilding dependants could become a problem in case of ABI breakages. But I don't believe that would be the case here.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2019-10-30 02:52:48 -0500

Seen: 416 times

Last updated: Oct 30 '19