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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
(text/plain)