[ros-users] catkin_make convenience improvements

[Thibault Kruse]

Hi all,

I raised some concerns over catkin_make convenience in a meeting, here 
are the results of the brainstorming. catkin_make is mostly a 
convenience wrapper to cmake/make, for usage with the catkin build 
system starting with ROS Groovy.

The current catkin_make design was guided by the desire to have a 
consistent and self-explaining workspace layout for tutorials and novice 
users, a quick way to create workspaces, and a wrapper around cmake to 
reduce cumbersome typing of common -D options.

In it's current state, catkin_make may not as convenient as it could be. 
Current quirks are:
- the workspace/src folder in itself is not popular with everybody
- it is inconvenient to have to cd into the workspace folder to invoke 
catkin_make
- it is inconvenient that wstool commands work in the src folder and 
below only, currently, meaning another "cd" step
- invoking catkin_make once with custom options (for build/src 
locations), and then again without options does not remember the last 
options, and retyping the options is also cumbersome.
- cleaning up builds (make clean, make distclean) does not work too well 
and is cumbersome, more support would be nice

Since REP128 (http://ros.org/reps/rep-0128.html) does not make a strong 
effort to justify the design it defines, we have to also look at some 
use cases and find justifications.

- We can consider 3 types of user groups who may want to use catkin_make
-- total noobs: Those need one source space, one build configuration and 
that's it
-- advanced programmers: Those may typically have 2 build 
configurations, one with debug settings, one with performance optimized 
settings
-- power users: Those may have a large number of build configurations 
for the same workspace, for cross compilation experiments and such
I assume the toplevel "src" folder allows to have some cleanliness in 
particular for power users, having multiple build, devel and install 
spaces at the workspace root level, and packages one level below. On the 
other hand, I assume it would be similarly clean if all build, devel and 
install spaces were stored away in workspace/builds, and packages else 
reside in the workspace root.

- catkin workspaces are used by several people using symbolic linking 
(for convenience, and maybe due to known limitations of catkin overlaying)

- catkin also does env_caching, which needs to be taken into account for 
sequences of buildspace creation actions

- there is also catkin_make_isolated, which currently creates a 
different folder layouts, maybe some consolidation could happen there as 
well



So some design strategies that we came up with regarding more 
flexibility of invoking catkin_make and setting up workspace layouts 
according to personal preferences.


Alternative "Marker-file":
This idea involves placing a marker file at the workspace root, which 
can be used by catkin_make as point of reference when invoked in a 
subfolder (and maybe also by roscd without arguments). To support 
invoking catkin_make without arguments with custom paths, the marker 
file could have content that defines build configurations, e.g. the last 
one that was specified. For users that typically have multiple build 
configurations, this could be extended to have differently named 
configurations. Probably cmake already caches options for us, so really 
what could be stored in the marker file would be the path to a build 
space. However build-spaces get nuked regularly  (since we have no great 
"clean" target), so duplication of information might still make sense in 
the marker file (unless we find a nice "clean" command).
Such a markerfile might also be made compliant with wstool, one way or 
the other. The disadvantage here is that some additional infrastructure 
is require, to be maintained.

Alternative "Build Env Switching":
This idea involves switching build configurations (rather than 
workspaces), meaning every build folder gets it's own file to source, 
like "setup.sh", though a different name might be better. Such a file 
would declare an env variable pointing to the build folder, and invoking 
catkin_make from anywhere would invoke cmake/Make in the folder of the 
env var (if set). Disadvantages are that this is less transparent to the 
user, requires the user to know about this setup file as well, and 
encourages the bad habit of reusing the same shell for different build 
environments.

So this is just brainstorming, and anyone who feels passionately enough 
about catkin_make is welcome to contribute ideas, opinions, (informal) 
votes. The next steps could be to write prototypes and a REP. Once we 
start doing that, we'll probably take the discussion to the ROS 
Buildsystem SIG, but I'd be happy to get some feedback by mere catkin users.

-- Thibault



PS: Some background discussion and ideas also here:

https://github.com/ros/catkin/issues/325
https://github.com/ros/catkin/issues/304
http://ros.org/reps/rep-0128.html
https://github.com/tkruse/rep/blob/rep0130/rep-0130.rst