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...
While changing to
catkin_toolsmight 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 tocatkin_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.catkin_make_isolatedmight be an easy switch but it doesn't offer processing packages in parallel. So for larger packages it doesn't offer a good performance. Besidecatkin_toolsyou might also want to consider tryingcolconwhich is the build tool of choice in ROS 2 but also works for ROS 1. In terms of performance it should be similar good ascatkin_tools- both support processing packages in parallel.I looked at the
FindCUDA.cmakefile, and rewriting looks very tricky...catkin_toolslooks like the best bet, although I'm having a separate problem that I'll make another post about.@KenYN: workspace overlaying doesn't work for you?
@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.
Wouldn't you just put the CUDA-affected packages in the underlay? At least that is what I understood is your problem right now.