On 02/19/2011 02:34 PM, Steven Bellens wrote:
> I'd like to upgrade the typegen support currently contained in the
> orocos_toolchain_ros stack. This is currently locked in to version
> 2.1.0.
> Ideally, I'd like to include utilmm, utilrb, typelib and orogen
> directly as git submodules. My question in this respect is:
> Are you willing to take in a default Makefile in every package
> providing ROS support - similar to what is available in rtt and ocl?
> (see example file for utilmm in appendix)
> This Makefile will only influence systems on which ROS_ROOT is
> defined. There is no change in any of the packages CMAKE code.
"YUK". Really. Isn't there any other way ?
> I noticed that the orogen typekit template code is not using the
> orocos macro's at the moment. Does anyone have any plans to update
> those already?
I don't. Is there a specific reason why it is needed ?
orogen in orocos_toolchain_ros
On Tuesday 22 February 2011 10:19:12 Sylvain Joyeux wrote:
> On 02/19/2011 02:34 PM, Steven Bellens wrote:
> > I'd like to upgrade the typegen support currently contained in the
> > orocos_toolchain_ros stack. This is currently locked in to version
> > 2.1.0.
> > Ideally, I'd like to include utilmm, utilrb, typelib and orogen
> > directly as git submodules. My question in this respect is:
> > Are you willing to take in a default Makefile in every package
> > providing ROS support - similar to what is available in rtt and ocl?
> > (see example file for utilmm in appendix)
> > This Makefile will only influence systems on which ROS_ROOT is
> > defined. There is no change in any of the packages CMAKE code.
>
> "YUK". Really. Isn't there any other way ?
There isn't. we could have it call autoproj in case ROS_ROOT is not set. This
would allow to 'make' in the top-level directory.
>
> > I noticed that the orogen typekit template code is not using the
> > orocos macro's at the moment. Does anyone have any plans to update
> > those already?
>
> I don't. Is there a specific reason why it is needed ?
I don't see any reason either after the trouble we had last time.
Peter
orogen in orocos_toolchain_ros
On 02/22/2011 01:38 PM, Peter Soetens wrote:
> On Tuesday 22 February 2011 10:19:12 Sylvain Joyeux wrote:
>> On 02/19/2011 02:34 PM, Steven Bellens wrote:
>>> I'd like to upgrade the typegen support currently contained in the
>>> orocos_toolchain_ros stack. This is currently locked in to version
>>> 2.1.0.
>>> Ideally, I'd like to include utilmm, utilrb, typelib and orogen
>>> directly as git submodules. My question in this respect is:
>>> Are you willing to take in a default Makefile in every package
>>> providing ROS support - similar to what is available in rtt and ocl?
>>> (see example file for utilmm in appendix)
>>> This Makefile will only influence systems on which ROS_ROOT is
>>> defined. There is no change in any of the packages CMAKE code.
>> "YUK". Really. Isn't there any other way ?
> There isn't. we could have it call autoproj in case ROS_ROOT is not set. This
> would allow to 'make' in the top-level directory.
Yuk again. But I guess that's going to happen anyway since ROS seems to
be important to you guys ;-)
orogen in orocos_toolchain_ros
2011/2/22 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 02/22/2011 01:38 PM, Peter Soetens wrote:
>> On Tuesday 22 February 2011 10:19:12 Sylvain Joyeux wrote:
>>> On 02/19/2011 02:34 PM, Steven Bellens wrote:
>>>> I'd like to upgrade the typegen support currently contained in the
>>>> orocos_toolchain_ros stack. This is currently locked in to version
>>>> 2.1.0.
>>>> Ideally, I'd like to include utilmm, utilrb, typelib and orogen
>>>> directly as git submodules. My question in this respect is:
>>>> Are you willing to take in a default Makefile in every package
>>>> providing ROS support - similar to what is available in rtt and ocl?
>>>> (see example file for utilmm in appendix)
>>>> This Makefile will only influence systems on which ROS_ROOT is
>>>> defined. There is no change in any of the packages CMAKE code.
>>> "YUK". Really. Isn't there any other way ?
>> There isn't. we could have it call autoproj in case ROS_ROOT is not set. This
>> would allow to 'make' in the top-level directory.
> Yuk again. But I guess that's going to happen anyway since ROS seems to
> be important to you guys ;-)
What's so bad about it? You're adding support for a second, popular
build system, in a non-intrusive way...
Steven
>
> --
> Sylvain Joyeux
> Space& Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
orogen in orocos_toolchain_ros
On 02/22/2011 04:22 PM, Steven Bellens wrote:
>>>> "YUK". Really. Isn't there any other way ?
>>> There isn't. we could have it call autoproj in case ROS_ROOT is not set. This
>>> would allow to 'make' in the top-level directory.
>> Yuk again. But I guess that's going to happen anyway since ROS seems to
>> be important to you guys ;-)
> What's so bad about it? You're adding support for a second, popular
> build system, in a non-intrusive way...
Adding a Makefile in the root of every package is not, in my book,
non-intrusive. They could have at least called it Makefile.ros
In general, having to always modify the packages to make them build
under rosbuild is not non intrusive.
I got some people at DFKI that came to us saying that rock was not
building (and being not happy about it). The reason ? They are also
using ROS and therefore ROS_ROOT was set. That's not a "non intrusive
integration".
So, yes, yuk. Now, as I said I'm not going to oppose it in any way.
orogen in orocos_toolchain_ros
On Tuesday 22 February 2011 16:48:36 Sylvain Joyeux wrote:
> On 02/22/2011 04:22 PM, Steven Bellens wrote:
> >>>> "YUK". Really. Isn't there any other way ?
> >>>
> >>> There isn't. we could have it call autoproj in case ROS_ROOT is not
> >>> set. This would allow to 'make' in the top-level directory.
> >>
> >> Yuk again. But I guess that's going to happen anyway since ROS seems to
> >> be important to you guys ;-)
> >
> > What's so bad about it? You're adding support for a second, popular
> > build system, in a non-intrusive way...
>
> Adding a Makefile in the root of every package is not, in my book,
> non-intrusive. They could have at least called it Makefile.ros
>
> In general, having to always modify the packages to make them build
> under rosbuild is not non intrusive.
>
> I got some people at DFKI that came to us saying that rock was not
> building (and being not happy about it). The reason ? They are also
> using ROS and therefore ROS_ROOT was set. That's not a "non intrusive
> integration".
FYI, there have been hickups in combining 'autoproj' with ROS_ROOT systems. On
the master branch, doing so is now supported, provided that you have your
packages in a ROS_PACKAGE_PATH as well. I am mixing autoproj with rosmake on
my development system.
The same holds for the bootstrap.sh script: it will only work with ROS_ROOT
set if you're running it in a subdir of your ROS_PACKAGE_PATH. I had a patch
for bootstrap.sh that checks if this condition is valid and warns if it's not.
>
> So, yes, yuk. Now, as I said I'm not going to oppose it in any way.
Peter