Sorry, it seems Dirk beat me to some of these things.
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 ~/workspacesrcbuilddevelinstall$ 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/develThis line would not be needed.
catkin_make --build .catkin/build --src . --devel .catkin/buildThis 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_argsI 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.shHow 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 BohrenPhD StudentDynamical Systems and Control LaboratoryLaboratory for Computational Sensing and RoboticsThe Johns Hopkins University_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users
--
William WoodallWillow Garage - Software Engineer