[ros-users] catkin_make convenience improvements

Tue Feb 5 23:31:49 UTC 2013

Thanks to all for contributing ideas. Here are some preliminary 
decisions in a nutshell, from a meeting today:

There shall be a marker file soon by which catkin_make can be invoked 
anywhere within the workspace folder, and the marker file will remember 
the folder layout from any last call, so removing all build artefacts 
and running catkin_make again shall create the same folder layout again.

The default folder layout remains as it is, there will not be any 
separate catkin_cmake command, and we try to avoid complex features.

The fineprint and justifications are discussed in the Buildsystem SIG, 
anyone is welcome to join there:
https://groups.google.com/d/topic/ros-sig-buildsystem/_1PWeIZvAbw/discussion

cheers,
   Thibault

On 30.01.2013 17:59, Thibault Kruse wrote:
> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users