Hi,
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.
>
> 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
+1
> - it is inconvenient to have to cd into the workspace folder to invoke
> catkin_make

This does break my workflow and although I am still mainly on rosbuild
my proposed solution is a wrapper script that does the following:
1. save the current directory (pushd)
2. cd .. until either at / or workspace folder is detected
3. catkin_make $@
4. Jump back (popd)

2. is a bit hacky: My definition of workspace folder is:
- there is a CMakeLists.txt
- that is a symlink
- to the main cmake in /opt/ros

The marker file that you discuss later could make this safer.
If more people need this a behavior it might be good to include that
into catkin_make by default.

Best,
   Christian

> - 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
+1

> 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


-- 
Albert-Ludwigs-University
Institute of Computer Science
Research Group Foundations of Artificial Intelligence
Georges-Köhler-Allee 52
79110 Freiburg
Phone: +49 761 203 8225