On Wed, Jan 30, 2013 at 6:31 PM, William Woodall <wwoodall@willowgarage.com> wrote:
On Wed, Jan 30, 2013 at 2:13 PM, Jonathan Bohren <jonathan.bohren@gmail.com> wrote:
On Wed, Jan 30, 2013 at 3:47 PM, Dirk Thomas <dthomas@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@willowgarage.com> wrote:
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!
-j

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

(707) 520-4736
jbo@jhu.edu