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:
>
>> (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@jhu.edu
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
--
William Woodall
Willow Garage - Software Engineer
wwoodall@willowgarage.com
(text/plain)