Sorry, it seems Dirk beat me to some of these things. 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. -- On Wed, Jan 30, 2013 at 3:31 PM, William Woodall 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 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 > -- William Woodall Willow Garage - Software Engineer wwoodall@willowgarage.com