ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
My recommendation is to always use the devel space (if that's your preference while hacking) and then separately do install once from scratch (maybe with a separate profile). Otherwise you could always install, but then you loose the ability to update headers and scripts and launch files and then have them take effect without running the build again.
Also, use ccache
if you are not, it can save a lot of time on the rebuild.
One of the core issues is that catkin_tools
(and catkin_make_isolated
) build one package at a time, source the result, then build another, whereas catkin_make
builds everything at once.
This can be a problem if an executable in pkg A links against a library in pkg B, because if you first run in --no-install
then the executable in A will be linked against a library in <devel>/pkg_B/lib
. Which is fine, but if you then make a change to the library in pkg B and switch to --install
, now the executable in pkg A might still be linked against the devel space version of B, when the latest version of B is in the install folder. This applies anytime you reference a file in the devel space of another package, like templating a location into a file or something like that, not just in linking.
The other issue is that since catkin_tools
(and again catkin_make_isolated
) can have plain cmake packages in their workspaces, in addition to catkin package (which catkin_make
can only handle), and those need to be installed to the "devel space" and then reinstalled to the "install space" if you switch the setting. This can work, but we experienced some pretty strange cases where it didn't.
So conceptually, there are some pitfalls when switching, so we made the decision (after trying a lot of things to resolve all of the "switching issues") to instead always recommend rebuilding, even though it might work sometimes.
Here are some issues where we discussed this:
In ROS 2 (using ament instead of catkin) we've tried to address this in a better way, by not using devel space (always installing), but instead providing a way to make symlinks rather than copies during the cmake install step. This way you can always install, but still get the benefit of updated headers, scripts, and launch files taking effect without a rebuild.