On 1 June 2010 12:20, Tully Foote wrote: > Bill, > Yes all those should be hidden inside the build directory.  Due to the many > different languages and styles we don't have a standard target for what > you're asking for. > > In terms of invoking it I would suggest just using make directly.  aka > "roscd my_pkg && make dist-clean"  To reiterate above the root Makefile > should always just be the call through to cmake.mk as Lorenz pointed out and > all the build artifacts will be hidden in the build directory. > > Daniel, > For your two requests: > >  1) we're working toward that goal, however guaranteeing that all the core > ROS runtime dependencies are built and ready is what that step is doing. > Using installed versions of ROS makes that step very quick due to the > ROS_NOBUILD as you suggested. > >  2) Quick answer, use a "--robust" option and it will continue.  Long > answer, the --target argument is available but can't be easily generalized, > for the missing/error responses you want for different build steps are > potentially quite different.  And the higherarchical nature of a rosmake no > longer makes sense when doing custom targets unless the whole ecosystem > knows about the custom target, in which case it's no longer a custom > target.  I would suggest possibly using something like "rosmake -s > target_pkg --target=custom_target" which is equivilant to doing "roscd > target_pkg && make custom_target"  And rosmake will take a list of packages > if you have more than one, or a stack if a whole stack has a target > defined. Actually, I think its ok as it is. I have a script which protects the ros core stack (or other stacks) rather conveniently - I'm not sure ros needs to provide anything beyond the ROS_NOBUILD feature in that regard. Using -s doesn't really work though, ok if its only a program or two, or a complete stack, but once the dependencies get compilcated, its nice to let rosmake do that for us. > On Mon, May 31, 2010 at 5:31 PM, Bill Morris > wrote: >> >> On Mon, 2010-05-31 at 16:37 -0700, Lorenz Mösenlechner wrote: >> > Hi, >> > >> > calling 'cmake CMakeLists.txt' in your package directory should >> > overwrite your existing Makefile with a cmake generated one. I'm not >> > sure if this is what you want to do and calling cmake outside a >> > dedicated build directory is not the right way to use cmake anyway. >> >> Was there a bug at some point where >> CMakeCache.txt >> cmake_install.cmake >> CMakeFiles/ >> were built outside of build/ and the primary Makefile was overwritten? >> It would explain things if that was not a feature and was in fact a bug. >> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > > -- > Tully Foote > Systems Engineer > Willow Garage, Inc. > tfoote@willowgarage.com > (650) 475-2827 > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- Phone : +82-10-5400-3296 (010-5400-3296) Home: http://snorriheim.dnsdojo.com/ Yujin Robot: http://www.yujinrobot.com/ Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl