[ros-users] [Orocos-users] orocos_toolchain_ros for debian
Ruben Smits
ruben.smits at mech.kuleuven.be
Wed Feb 23 08:00:55 UTC 2011
On Tuesday 22 February 2011 23:55:26 Willy Lambert wrote:
> 2011/2/22 Peter Soetens
> <peter at thesourceworks.com<mailto:peter at thesourceworks.com>>
>
> On Monday 21 February 2011 00:32:05 Willy Lambert wrote:
> > 2011/2/8 Willy Lambert
> > <lambert.willy at gmail.com<mailto:lambert.willy at gmail.com>>
> >
> > >>> The standard way to run executables in ROS packages is with
> > >>> rosrun,
> > >>> e.g;
> > >>>
> > >>> rosrun ocl deployer-gnulinux
> > >>
> > >> Oh yes ! I still don't have the ROS reflexes :)
> > >
> > > it answers :
> > > ard at ard-host-v5:/media/DD_data/home/ard$ rosrun ocl
> > > deployer-gnulinux
> > > [rosrun] You have chosen a non-unique executable, please pick one of
> > > the following:
> > > 1) /home/ard/ros/orocos_toolchain_ros/ocl/bin/deployer-gnulinux
> > > 2)
> > > /home/ard/ros/orocos_toolchain_ros/ocl/install/bin/deployer-gnulinu
> > > x
> > > #?
> > >
> > > I know there are egal because one is the "make installed" version
> > > of the
> > >
> > > other, by I find it is strange and prevent from starting it
> > > automatically after boot (of course I have solutions to avoid this,
> > > but the rosway should work no ?)
> > >
> > > I makes me thinking about folder size and orocos_toolchain_ros is
> > > 1,7Gb
> > > on my computer x-( I know there is some hard work on code size
> > > reduction on the Orocos side but nearly 2gb is quite huge.
> > >
> > > Does it exist a "rosmake clean" instruction ?
> >
> > Let me up this subject,
> > after having built the orocos_toolchain_ros it seems it's a bit messy
> > with build and installed files. Firstly, rosrun find 2 executables for
> > deployer-gnulinux and can't choose.
>
> We're still looking on how to solve this. The problem is that we require a
> 'make install' in ocl because the headers are included using
> 'ocl/Header.hpp' by user code, while they are in the sources in
> 'subproject/Header.hpp'. We discussed moving all headers to the ocl/
> directory, but this somewhat beats the purpose of the modularisation we
> did. An alternative would be to create symlinks from ocl/Header.hpp to
> subproject/Header.hpp in ROS_ROOT
> environments. This might be the least intrusive step for now.
>
> Ok, but here it's about a binary
>
> > Secondly after having used "make clean"
> > in all the packages of orocos_toolchain_ros stack, it reduced from
> > nearly
> > 2gb to 350Mb with is by far more acceptable. Is it any "ros" tool to do
> > this ? Would it be possible to add a global "make clean" at the root of
> > orocos_toolchain_ros ?
>
> Did you compile with MinSizeRel ?
>
> I used the default configuration and didn't thougth about this.
> How may I change this with rosmake ?
>
There are different things you can use: I suggest you just edit the orocos-
rtt.default.cmake file.
>
> The make clean is not what you want, since
> it will also remove the libraries of the normal 'ros' packages, which don't
> have an install step (so it only makes sense for RTT and OCL right now).
>
> People are looking at how to reduce code size, but for a development system,
> it's always handy to have the .o files still there....
>
> of course it is. But it is also handy to have a clean function before
> copying on the robot (and not to embed the sources).
>
> In the "classic" orocos toolchain installation I used to copy the install
> folder onto my target with the same path as on the building machine. If I
> could create my_orocos_toolchain.deb easily I would install then on my
> robot instead of copying.
You could strip the orocos_toolchain_ros rtt and ocl packages after building
and before copying it. AFAIK you can entirely remove the build directory.
> As there is no "install" step yet in ROS, I just copy the complete ros_root
> folder containing all the stacks (including orocos_toolchain_ros) onto the
> target. So the .o goes with it. Maybe I could do better, but I don't know
> how to do it
>
>
>
>
> Peter
-- Ruben
More information about the ros-users
mailing list