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