[ros-users] catkin_make convenience improvements

Jonathan Bohren jonathan.bohren at gmail.com
Fri Feb 1 16:20:55 UTC 2013

On Fri, Feb 1, 2013 at 6:07 AM, Thibault Kruse <kruset at in.tum.de> wrote:

> On 30.01.2013 21:47, Dirk Thomas wrote:
>> For catkin that means it is based on CMake because that is one of the
>> most used tools for building C++.
>> And therefore catkin aims to keep the standard CMake workflow working -
>> so the user can build stuff just as he does with vanilla CMake.
> This made me think of the separation between configure and build steps.
> Cmake has two separate commands for this, while catkin_make currently both
> wraps cmake and make invocations. Merging the arguments to both cmake and
> make into a single command might not be the right approach then.
> E.g. having catkin_cmake or catkin_configure to wrap calls to cmake, and
> catkin_make to wrap calls to make might be a better representation of the
> cmake workflow.
> Thought I would be happy to add to catkin_configure features that provide
> users with nice defaults for having both a debugging build configuration
> and an optimized build configuration without the user having to understand
> the details of cmake -D options or even c++ compiler settings first.

Yeah, if we could basically use catkin_cmake and catkin_make to streamline
development by giving users the capability to run cmake and make in the
appropriate directories for the catkin workspace without actually having to
navigate to them, that would be great.

> On 30.01.2013 21:18, Jonathan Bohren wrote:
>> What if, given a workspace, we could just have a bunch of source packages
>> and then we could put all of the "build", "devel", and "install"
>> directories under a hidden directory called ".catkin".  Then, inside of the
>> ".catkin" directory we could have a config.yaml file. This combination of
>> ".catkin/config.yaml" will act as the marker file, and keep the workspace
>> focused on the source code instead of the buildsystem.
> We can keep in mind having separate subfolders wrapping a build, devel and
> install space that belong together. That might be more useful than to have
> to manually manage this tripel of folders via naming conventions. The
> build, devel and install space are in my opinion far too prominent in the
> current workspace layout, given that to most users, it is the source that
> is most relevant as working material.
> Regarding using a hidden folder, I do see the problem with using find
> commands, but on the other hand users already benefit from using find
> commands that ignore hidden folders, such as to not waste time (and get
> undesired results) grepping through .git and .svn subfolders when searching
> through code. But I struggle to see this as a novice-friendly default as
> well, as it is so unlike cmake default usage.

What if we just had two directories in a workspace: "catkin" and "src" (or
catkin_build and catkin_src) and then it doesn't hide anything, is even
more descriptive, and also satisfies Will's desires to keep the source in
an isolated space. Then inside of catkin or catkin_build there is a
build,devel,install or cmake_build,devel,install or something similar?

>  I feel like ROS already has an abstraction layer in place that catkin
>> could be dropped into so that by I???turtle, you can just call "rosmake" to
>> invoke catkin from an arbitrary place like directory, and you wouldn't even
>> know it's using catkin.
> The rosmake abstraction layer does not consider things like install
> targets and multiple build configurations. So while it might be technically
> feasible to circumvent catkin workspaces and build catkin packages with an
> extended rosmake, the benefit would probably not justify the effort. On the
> other hand building rosbuild projects as part of a catkin workspace might
> be something that is feasible using catkin_make_isolated. If feasible, that
> would be an easier sell to the catkin maintainers, in particular since we
> currently suffer that users have to set up two different workspaces using
> two rosinstall files to build all of ROS from source.

I was moreso talking about just making catkin work like rosmake for novice
users, where they'd have a catkin workspace, with catkin packages, and they
could be inside some arbitrary directory and call "rosmake" but that would
really just be an alias to "catkin_make". But this is just talking about
the workflow more than it was any sort of backwards-compatibility.

That being said, it would definitely be great if you could put rosbuild
packages in a catkin workspace.

> As to having a build system that that does not get in the way of users, I
> believe catkin_make can get there after this discussion.

Yeah, I'm confident it will get there!


Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University

(707) 520-4736
jbo at jhu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130201/ffd6b383/attachment-0004.html>

More information about the ros-users mailing list