[ros-users] catkin_make convenience improvements

[William Woodall]

On Wed, Jan 30, 2013 at 2:13 PM, Jonathan Bohren
<jonathan.bohren at gmail.com>wrote:

> On Wed, Jan 30, 2013 at 3:47 PM, Dirk Thomas <dthomas at willowgarage.com>wrote:
>
>> (even if you can with the current catkin by passing in custom folder for
>> build/devel/install).
>>
>> Anyway we are looking for ways to make catkin_make have a bit more sugar
>> to make that tool easier and more convenient to use.
>
>
> Then what if we support the following new but thin, tools for people who
> want to use catkin_make instead of full-on-catkin but don't like having to
> jump around their filesystem in the standard CMake workflow.
>

The only improvement this proposal has is that it can be done from the
source space.  I agree with Dirk that hiding files in a .catkin folder is
not desirable, visibility is important, especially for people who are
unfamiliar with this development model.

As for the source space folder, aka `workspace/src`, my opinion is that it
is an improvement on having all of the packages in the root of the
workspace. The reason I say that is that having the source code not be
direct peers of the build, devel, and install spaces makes searching it
with simple tools easier.  For example:

# I can search just the pristine source space
$ cd ~/workspace/src
$ grep -r "#ifndef ROSCPP_ROS_H" .
./roscpp/include/ros/ros.h:#ifndef ROSCPP_ROS_H

# Or I have to search the build and install and devel spaces too
$ cd ~/workspace
$ ls ~/workspace
src
build
devel
install
$ grep -r "#ifndef ROSCPP_ROS_H" .
./install_isolated/include/ros/ros.h:#ifndef ROSCPP_ROS_H
./src/roscpp/include/ros/ros.h:#ifndef ROSCPP_ROS_H
./build/....

You can work around this with excludes and other things, but this is a
distinct advantage from my point of view. On the other hand I can't think
of a reason for having the source packages be direct peers of the other
spaces...  The only real reason is that currently the tool doesn't let you
run catkin_make from anywhere in the workspace, but we are proposing to fix
that.


> Note I use the current catkin_make script in `catkin init` to illustrate
> what that should do. Also note that this preserves what are basically
> pass-through calls to cmake and make
>
> `catkin init`:
>     mkdir -p .catkin/build .catkin/install .catkin/devel
>

This line would not be needed.

    catkin_make  --build .catkin/build --src . --devel .catkin/build
>

This would be: `catkin_make --build .catkin/build --src .
-DCATKIN_DEVEL_PREFIX=.catkin/devel`

The devel prefix is defined purely in cmake and we intended it that way.
Also, just as a note, you don't want to point your devel and build space to
the same folder, this would be like installing your normal cmake project to
your cmake build folder.

Also, `catkin_make` would have run cmake and make already so the follow
commands are not necessary unless you want to run them explicitly.

`catkin cmake [cmake_args]`:
>     cd /path/to/ws/.catkin/build && cmake /path/to/ws $cmake_args
> `catkin make [make_args]`:
>     cd /path/to/ws/.catkin/build && make $make_args
>  `catkin ninja [ninja_args]`:
>     cd /path/to/ws/.catkin/build && ninja $ninja_args
>

I wouldn't think we would support ninja since cmake doesn't come with a
native generator for it. Even then we don't support the other generators
that cmake provides.

`catkin source`:
>     source /path/to/ws/.catkin/devel/setup.sh
>

How should it know which space to source?  If I just ran `catkin_make
--install` on a clean workspace I now have a valid devel and install space
of which I could source either.  Would this information be stored in the
marker file or ...?


>
> Also it's worth noting that the current version catkin_make ignores the
> "--devel" argument.
>

It does not have a `--devel` argument.


>
> -j
>
> --
> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
William Woodall
Willow Garage - Software Engineer
wwoodall at willowgarage.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130130/3b657b86/attachment-0004.html>