On Wed, Jan 30, 2013 at 2:13 PM, Jonathan Bohren wrote: > On Wed, Jan 30, 2013 at 3:47 PM, Dirk Thomas 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