Add install verb, also do not force re-build when changing the Install space

[ecward]

System Info

• Operating System: uname -a Linux rcv-GS60-6QE 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Python Version: python --version Python 2.7.12
• Version of catkin_tools: catkin --version OR Git revision catkin_tools 0.4.4 (C) 2014-2018 Open Source Robotics Foundatio
• ROS Distro: echo $ROS_DISTRO kinetic

Build / Run Issue

This page does not exist

• [ ] Works with catkin_make
• [ ] Works with catkin_make_isolated --merge
• [ ] Works with catkin build
• [ ] Works with catkin build -p1
• [x] I did not read this

Expected Behavior

When changing the install space with: "catkin config -i filename" you should NOT have to do catkin clean -b.

You should be able to type "catkin install" to to install to install space, this should NOT happen when you use "catkin build". If you set the install space to /opt/ros/kinetic you SHOULD still be able to build without sudo. You SHOULD be able to do sudo catkin install to install to /opt/ros/kinetic

Actual Behavior

You have to rebuild everything after changing install space (you get a warning that tells you to do catkin clean -b)

You cannot do catkin build (without sudo) if you set install space to /opt/ros/kinetic

Steps to Reproduce the Issue

[wjwwood]

I think there are some conceptual challenges with what you're proposing.

When changing the install space with: "catkin config -i filename" you should NOT have to do catkin clean -b.

That would be nice, but it's a tricky problem to address without fail. Most of the time you can simply "do it", but there were enough corner cases which required you to do something more complicated or just start over, that we suggested that you start with it on or start over when changing it.

It could be addressed though, however I wouldn't probably address it as you've proposed here. I'd simply improve the logic that switches to --install to fix any corner cases or at least detect the corner cases and only suggest catkin clean -b when they are detected.

You should be able to type "catkin install" to to install to install space, this should NOT happen when you use "catkin build".

This is conceptually not possible when you consider non-catkin packages (like pure CMake packages). They must be installed in order for another package to utilize them.

For example, if you assume the build process of cmake .., make, make install, and you have package A which depends on package B. In that scenario, you cannot reasonably expect A to be able to use B if you only do cmake .. and make. Most likely A will not be able to find B, even if the specified install target is added to the CMAKE_PREFIX_PATH or whatever. So if you want to do catkin build on a workspace containing them both, you cannot build A unless you install B first.

Even with catkin packages, switch from the devel space to the install space is a problem. Consider you have two catkin packages A and B where again A depends on B. If you first build with the "devel" spaces, then package A will find package B, but it will find it's resources in the devel space of B (not the install space). This is convenient to avoid having to run make install, but if later you run make install on B and then A, A still might be referring to artifacts and resources in the devel space of B, which is not what you want. This is why switch is problematic.

If you set the install space to /opt/ros/kinetic you SHOULD still be able to build without sudo.

I agree this would be nice, and it is possible with catkin packages because you can use the devel space, but if there are any non-catkin packages then you again cannot assume they can be used by dependent packages unless they are installed. As well the same switching issues apply.

This is just a conceptual difference to building one things versus building many things together at once.

One option is that we could install to a temporary place when you do a "build" but then copy that installation on "install" to the target location, e.g. /opt/ros/kinetic. This is sort of how DESTDIR works and all the packages and tools would need to support this case, which is generally referred to as "relocatable installs".

You SHOULD be able to do sudo catkin install to install to /opt/ros/kinetic

Again, this doesn't consider the fact that you need to chain make then make install for each package in dependency order.

The proposed solution for this use case has always been to have an option to do the make install step as sudo but not the rest of the build. So you'd do something like catkin build --install-with-sudo and it would do cmake and make as the current user, but use sudo with make install.

W.r.t. the catkin install verb, I don't think that makes sense, again unless it's a "fake install" that just copies the installed packages into a new destination. With the explanation about needing to install before build then next package, I hope the reason I feel that this verb isn't possible makes sense.

I'm going to close this, as I don't see a way to implement what is proposed in a conceptually consistent way. There are at least two other enhancement requests here which might make sense as new issues (you should check to see if there are existing issues before opening new ones) which are:

• should be able to switch from --no-install to --install or vice versa without catkin clean -b
• should be able to install packages with sudo but build without (implies --install-with-sudo option)

Feel free to continue commenting and iterating on this topic here. I can reopen the issue if necessary.

[NikolausDemmel]

To add @wjwwood's explanation of why things are the way they are, maybe it is also helpful to consider why you would want to frequently switch between install and devel mode for single workspace, such that clean & rebuild is a nuisance? If you can describe the scenario that makes this necessary, maybe someone can suggest alternative approaches. I would say that probably most developers work mostly with a "non-install" catkin config, i.e. for development they only work with the devel space (which of course typically overlays a system-wide install, e.g. in /opt/ros, installed from binary packages).

Maybe in your case you can split the workspace up into 2. One with the packages that you don't develop, but just update sometimes and need to install (for some reason). The install space of this catkin workspace would then be an underlay for the second workspace with the packages you actively develop. That overlaying catkin workspace would never get the --install option.

Note that you can also make use of catkin profiles to switch quickly between different configurations in the same workspace without cleaning either.

[ecward]

@wjwwood and @NikolausDemmel thank you for your input. I now have a better understanding of the complications of this issue.