Compartmentalised catkin_make

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

Asked by KenYN on 2019-10-30 02:52:48 UTC

Comments

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.

Asked by jarvisschultz on 2019-10-30 16:23:22 UTC

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.

Asked by Dirk Thomas on 2019-10-30 21:27:48 UTC

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.

Asked by KenYN on 2019-10-31 02:43:42 UTC

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

Asked by gvdhoorn on 2019-10-31 09:03:14 UTC

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

Asked by KenYN on 2019-10-31 20:33:13 UTC

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

Asked by gvdhoorn on 2019-11-02 08:35:30 UTC

Answers

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.

Asked by gvdhoorn on 2019-10-30 11:46:28 UTC