[ros-users] catkin_make convenience improvements

Jonathan Bohren jonathan.bohren at gmail.com
Thu Jan 31 02:04:02 UTC 2013

On Wed, Jan 30, 2013 at 6:31 PM, William Woodall
<wwoodall at willowgarage.com>wrote:

> 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:
>>> 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.

Then that would be a great feature to have! I think being able to call
cmake and/or make from anywhere in a given catkin workspace would make the
system a lot friendlier.

> 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.

I think having the above feature would make my desire to hide the
directories to keep things uncluttered for novice users moot.

> 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

Yeah, I agree that this use case would require additional user effort to
remain clean if the source files were peers with the build files.

>  `catkin init`:
>>     mkdir -p .catkin/build .catkin/install .catkin/devel
> This line would not be needed.

We can't have a script automatically create the default workspace structure?

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

Cool, thanks for pointing that out.

> 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.

Yeah, that was just a copy-paste typo.

> 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.

I was just putting that there to emphasize that you could do this without
limiting accessibility to any of CMake's capabilities. That being said,
what limitation is preventing the use of ninja to build something with
catkin if your install of CMake supports it?

>  `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 ...?

It could take the workspace path as an argument, or a default value could
be stored in a file in your home directory. I use a similar alias for use
with rosws/wstool. In my bashrc I have the following:

alias savews='echo -e "$(pwd)" > ~/.curws'
alias loadws='source $(cat ~/.curws)/setup.bash'

Then you can easily store your "deafault" workspace for a session as you
open up new shells.

On Wed, Jan 30, 2013 at 6:35 PM, William Woodall <wwoodall at willowgarage.com>

> I see where you are coming from on these suggestions, and I agree we need
> to work on making the tools easier to use, but I think being able to run
> `catkin_make` from any sub folder of the workspace (after running it there
> the first time) combined with a good "clean" and "dist clean" option will
> make the tool much more usable.

Yeah, I think those sort of features would be great!

Thanks for the feedback!

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/20130130/f4b333f2/attachment-0004.html>

More information about the ros-users mailing list