With respect to #1, this is something that we are working on
internally, i.e. making a clean separation between the build system
and the runtime system. For now, if  you really want to disable the
extra building, then you should take a look at
rosmake/src/rosmake/rosmake.py and modify the 'always_build' variable.
NOTE: you will have to manually build these packages to successfully
build the runtime components of ROS.

 - Ken

On Fri, Apr 2, 2010 at 3:43 AM, Daniel Stonier <d.stonier@gmail.com> wrote:
> Hi all,
>
> I don't know if other people are finding the same thing, but we're
> finding the ros as a nice cmake enabled build environment...fullstop.
> Quite apart from the robot specific, runtime capabilities it has,
> we're currently using it to manage other projects that never actually
> depend on roscpp (or the python variant).
>
> One is a simple ubuntu .deb build farm using cmake/cpack. Another is
> used to cross-compile and manage a group of libraries/programs for an
> embedded product - the ros build environment takes care of
> dependencies, cflags and linking automatically, which greatly reduces
> management effort.
>
> Are there many others having the same experience?
>
> Which brings me to some points which seem a bit rough around the
> edges, especially for cross-compiling. Or maybe I'm just attacking it
> the wrong way. Either way, it would be good to hear some different
> opinions about best practice.
>
> 1) When not depending on any ros package:
>
> Running rosmake will still try and build some 13 extra packages
> (roscpp, rosout, rostest, ...). Is there a reason for this? I can't
> find any way around preventing them compiling apart from putting a
> ROS_NOBUILD in each package directory.
>
> 2) What is the most convenient way to do something like a custom target?
>
> Often I'd like to run a custom target built into some of our packages
> with rosmake - e.g. for downloading, packaging or installation to
> something like a cross-compiled filesystem root for an embedded board.
> However, even if the custom target is specified in your packages,
> they'll still run into problems when trying to compile those 13
> packages (above).
>
> 3) Extracting Packages to be Installed
>
> Another situation currently developing is one for which we're now
> considering supporting multiple robots. Our list of packages is
> getting rather large (not even including official ros stacks) and any
> single robot's compile is usually managed by a simple meta-package.
> With rosmake, life's great - it automatically does things so it only
> compiles a small fraction of all installed packages. However, when it
> comes time to set the system up on the robot, what's the usual
> procedure? I don't wish to copy (if cross compiling) or rebuild the
> whole development tree - that's an increasing amount of space being
> taken up by unused packages. Secondly I really only need the binary
> files - all those dev files take up alot of space. Thirdly, the other
> option I can think of is having a very customised rosinstall for each
> robot which seems a bit awkward - it's manually doing the job of
> intelligently finding what's needed that rosmake is already doing.
>
> One way to do it that I can think of would be to use a custom target
> for install. However that has issues (above) and needs extra
> consideration on how to standardise variables like install location,
> etc.
>
> Regards,
> Daniel Stonier.
>
> --
> 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
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>