# catkin config --install and --no-install using same build dir?

With catkin_make (and earlier versions of catkin tools?) I was able to build to either devel or install, but with catkin config I have to clean and rebuild everything when switching from one to the other- it would be less trouble to use a two profiles:

Error: Attempting to build a catkin workspace using build space: "/home/lucasw/catkin_ws/build" but that build space's most recent configuration differs from the commanded one in ways which will cause problems. Fix the following options or use catkin clean -b to remove the build space:
- install: True (stored) is not False (commanded)
\$ catkin clean -b

[clean] Warning: This will completely remove the following directories. (Use --yes to skip this check)
[clean] Build Space:   /home/lucasw/catkin_ws/build

[clean] Are you sure you want to completely remove the directories listed above? [yN]: y
[clean] Removing buildspace: /home/lucasw/catkin_ws/build


Or is there another way to do it that uses the least amount of building and rebuilding? (The second profile approach still requires a duplicate build, but at least doesn't need to be deleted) It seems like if all the cmake args are the same then one build should be able to either be used in place or installed (or dynamic libraries are built differently?)

edit retag close merge delete

Sort by » oldest newest most voted

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.

more

You can also use different profiles for install and devel, see https://catkin-tools.readthedocs.io/e... and https://catkin-tools.readthedocs.io/e...:

• have your default profile for devel
• have your myinstall profile for install

This way you don't have to rebuild everything from scratch when you want to switch. You can do the same for debug and release builds. Make sure you set the -x option, such that build etc directories are unique for each profile.

more