catkin-related changes in orogen

Submitted by Sylvain Joyeux on Mon, 2013-12-30 13:05

RTT-dev

Hi.

Could I have some overview of what you are changing in the orogen
templates ? I hope you have not forgotten how much you broke orogen two
or three years ago by not double-checking build system changes with the
main orogen users, namely the rock developers.

Right now, I have a few minor obvious issues, and a big question mark on
how it would affect orogen-generated packages in Rock.

Sylvain

catkin-related changes in orogen

Submitted by Ruben Smits on Tue, 2013-12-31 14:08.

Hi Sylvain,

On Mon, Dec 30, 2013 at 2:05 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> Hi.
>
> Could I have some overview of what you are changing in the orogen
> templates ? I hope you have not forgotten how much you broke orogen two
> or three years ago by not double-checking build system changes with the
> main orogen users, namely the rock developers.
>
>
First of all, if I'm not mistaken we are not pushing any of our changes on
the branches used by Rock, only to toolchain-2.7

Most of the changes relate to using the orocos cmake macros in the CMake
templates, which seem to make sense to me. Normally this should not break
anything as the orocos cmake macros are reasonably well tested for three
different use cases: plain cmake, catkin and rosbuild. Actually we have
also found some bugs in the cmake code of the templates (overwriting
previously set linking flags etc.), which have been solved by switching to
the use of the orocos cmake macros.

If you see any regression, please report. (Note that currently there is
still a small issue which causes to duplicate the orocos-target suffix for
the libraries. I'm fixing this as soon as I'm behind a development machine
again.)

> Right now, I have a few minor obvious issues, and a big question mark on
> how it would affect orogen-generated packages in Rock.
>
>
Please spit out your issues, I'm currently only changing and testing the
generated typekits, as that is the only thing we use of orogen and not
touching anything else. We are also not tracking any of the orogen changes
in next/master since previous trials did not work out of the box.

Ruben

> Sylvain
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 12/30/2013 08:22 PM, Ruben Smits wrote:
> Hi Sylvain,
>
> On Mon, Dec 30, 2013 at 2:05 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>> wrote:
>
> Hi.
>
> Could I have some overview of what you are changing in the orogen
> templates ? I hope you have not forgotten how much you broke orogen two
> or three years ago by not double-checking build system changes with the
> main orogen users, namely the rock developers.
>
>
> First of all, if I'm not mistaken we are not pushing any of our changes
> on the branches used by Rock, only to toolchain-2.7
Yes, however I guess you want to push them to master at some point, or ?
Moreover, I usually need to merge toolchain-2.7 to master every once in
a while, since it contains also non-build-related bugfixes (not so often
in orogen, I give you that)

> If you see any regression, please report. (Note that currently there is
> still a small issue which causes to duplicate the orocos-target suffix
> for the libraries. I'm fixing this as soon as I'm behind a development
> machine again.)
The issue here, as always, is the lack of communication. If I wasn't
closely looking at the changes in the orogen repo, I would not have
spotted that work *at all* and then what ? I get the regressions when
you merge in master ?

I'll make a list of issues (from reading the commits)

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

Hi Sylvain,

On Thu, Jan 2, 2014 at 10:10 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 12/30/2013 08:22 PM, Ruben Smits wrote:
>
>> Hi Sylvain,
>>
>> On Mon, Dec 30, 2013 at 2:05 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>> <mailto:sylvain [dot] joyeux [..] ...>> wrote:
>>
>> Hi.
>>
>> Could I have some overview of what you are changing in the orogen
>> templates ? I hope you have not forgotten how much you broke orogen
>> two
>> or three years ago by not double-checking build system changes with
>> the
>> main orogen users, namely the rock developers.
>>
>>
>> First of all, if I'm not mistaken we are not pushing any of our changes
>> on the branches used by Rock, only to toolchain-2.7
>>
> Yes, however I guess you want to push them to master at some point, or ?
> Moreover, I usually need to merge toolchain-2.7 to master every once in a
> while, since it contains also non-build-related bugfixes (not so often in
> orogen, I give you that)
>
>
Well, I would leave that to you, once you are convinced that it does not
break anything in master.

>
> If you see any regression, please report. (Note that currently there is
>> still a small issue which causes to duplicate the orocos-target suffix
>> for the libraries. I'm fixing this as soon as I'm behind a development
>> machine again.)
>>
> The issue here, as always, is the lack of communication. If I wasn't
> closely looking at the changes in the orogen repo, I would not have spotted
> that work *at all* and then what ? I get the regressions when you merge in
> master ?
>
>
Let me be free that this lack of communication is a two-directional
problem. What is the current status of orogen, would you advise us to merge
orogen/master to toolchain-2.7 if you know we only use typegen?

> I'll make a list of issues (from reading the commits)
>

Ok, I'm currently still fixing one issue with target names and target
directories. Once that's fixed I would like to create a Release Candidate
again. I'm eagerly waiting for your issues.

Ruben

>
> --
> Sylvain Joyeux (Dr.Ing.)
> 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
> -----------------------------------------------------------------------
>

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 01/02/2014 10:25 AM, Ruben Smits wrote:
> I'll make a list of issues (from reading the commits)
>
>
> Ok, I'm currently still fixing one issue with target names and target
> directories. Once that's fixed I would like to create a Release
> Candidate again. I'm eagerly waiting for your issues.
>
The easy-to-spot ones:
- does the RTT macros still look into package.xml/manifest.xml to
auto-add dependencies ? If yes, is there a way to disable it ? (This
is an absolutely-no-way in a rock context)
- the renaming of the regen and check-typekit-uptodate are really
problematic as (1) it gets super annoying to type the regen target
on the command line and (2) it breaks autobuild. Could you at least
create global targets with the original names (regen and check-
typekit-update) if they do not exist already and then add the
dependency to the new ones ?

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

On Thu, Jan 2, 2014 at 4:28 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/02/2014 10:25 AM, Ruben Smits wrote:
>
>> I'll make a list of issues (from reading the commits)
>>
>>
>> Ok, I'm currently still fixing one issue with target names and target
>> directories. Once that's fixed I would like to create a Release
>> Candidate again. I'm eagerly waiting for your issues.
>>
>> The easy-to-spot ones:
> - does the RTT macros still look into package.xml/manifest.xml to
> auto-add dependencies ? If yes, is there a way to disable it ? (This
> is an absolutely-no-way in a rock context)
>

Some information about the changes in the macros can be found here:
https://github.com/orocos-toolchain/rtt/pull/17
https://github.com/orocos-toolchain/rtt/pull/19
https://github.com/orocos-toolchain/rtt/pull/20

The issue we are trying to tackle with the changes in orogen is found here:
https://github.com/orocos-toolchain/rtt/issues/13

To summarize (Johannes, please correct me if I'm wrong):

the RTT macros will always link with the orocos_rtt libraries, I suppose
this is still OK for you. For the dependencies it depends on the buildtool
which is used, but can always be overridden by a cmake
flag: OROCOS_NO_AUTO_LINKING which by default is set to FALSE (autolinking
performed, I guess we need to invert the default!!!):

* The default pure cmake case:

Two macros are used to fill the following variables:
USE_OROCOS_PACKAGES
USE_OROCOS_LIBRARIES
USE_OROCOS_INCLUDE_DIRS
USE_OROCOS_LIBRARY_DIRS

First of all there is an orocos_find_package which fills PKG_* variables
and only works recursively in rosbuild enabled builds, it uses pkgconfig
under the hood, it takes an argument OROCOS_ONLY to only find orocos
packages.

Secondly there is an orocos_use_package that will append the previously set
PKG_* variables of orocos_find_package to the USE_OROCOS* variables.

In any case autolinking (done on a per target level) is only performed if
the OROCOS_NO_AUTO_LINKING flag is set to FALSE.

* In case of plain cmake:

OROCOS_NO_AUTO_LINKING is set to FALSE by default (can be overridden) and
orocos_use_package is performed on all dependencies in the manifest.xml
recursively without OROCOS_ONLY.
I guess this is not what you want. You can still override by
setting OROCOS_NO_AUTO_LINKING to TRUE. But maybe we should change the
default behaviour?

* In case of rosbuild (detected by a cmake flag set by the rosbuild_init
cmake macro which is not part of the template CMakeLists.txt anymore):

OROCOS_NO_AUTO_LINKING is set to FALSE by default (can be overridden) and
orocos_use_package is performed on all dependencies in the manifest.xml
recursively without OROCOS_ONLY

* In case of catkin (detected by a cmake flat set by calling catkin_make?):

OROCOS_NO_AUTO_LINKING is set to dependencies are searched
(non-recursively!!!) from the package.xml file. orocos_use_package is
called with OROCOS_ONLY: nly the packages that are identified as orocos
packages will be appended to the USE_* cmake variables, but by default
autolinking is set to false, so no autolinking is done.

> - the renaming of the regen and check-typekit-uptodate are really
> problematic as (1) it gets super annoying to type the regen target
> on the command line and (2) it breaks autobuild. Could you at least
> create global targets with the original names (regen and check-
> typekit-update) if they do not exist already and then add the
> dependency to the new ones ?
>
>
Seems reasonable to me. So you want a single target regen and
check-typekit-uptodate that will trigger all individual ones?

Ruben

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 01/02/2014 10:25 AM, Ruben Smits wrote:
> Let me be free that this lack of communication is a two-directional
> problem. What is the current status of orogen, would you advise us to
> merge orogen/master to toolchain-2.7 if you know we only use typegen?
Yes. To me, this was implicit as we *share* master. Everything I push to
master I expect it to be useful and beneficial for the orocos-toolchain
users. Namely, in the last months, support for inheritance.

I would *never* have used a common repository otherwise.

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

Hi Sylvain,

On Thu, Jan 2, 2014 at 10:29 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/02/2014 10:25 AM, Ruben Smits wrote:
>
>> Let me be free that this lack of communication is a two-directional
>> problem. What is the current status of orogen, would you advise us to
>> merge orogen/master to toolchain-2.7 if you know we only use typegen?
>>
> Yes. To me, this was implicit as we *share* master. Everything I push to
> master I expect it to be useful and beneficial for the orocos-toolchain
> users. Namely, in the last months, support for inheritance.
>
>
Ok, I just looked at orogen/master. Apparently a new dependency was added:
metaruby. Where do we need to fetch this dependency from, after googling it
seems that there are multiple different projects using this name.
Should we add it as a submodule to the toolchain repository? Is it a plain
ruby package that we can easily install in a systempath?

Ruben

> I would *never* have used a common repository otherwise.
>
> --
> Sylvain Joyeux (Dr.Ing.)
> 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
> -----------------------------------------------------------------------
>

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 01/02/2014 10:40 AM, Ruben Smits wrote:
> Ok, I just looked at orogen/master. Apparently a new dependency was
> added: metaruby. Where do we need to fetch this dependency from, after
> googling it seems that there are multiple different projects using this
> name.
> Should we add it as a submodule to the toolchain repository? Is it a
> plain ruby package that we can easily install in a systempath?
>

All your answers are in the autoproj build configuration (and in the
email you sent to ask about metaruby on orocos-dev in september !)

https://gitorious.org/orocos-toolchain/autoproj/source/ddb2eb137fd0b29c6...

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

On Thu, Jan 2, 2014 at 10:56 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/02/2014 10:40 AM, Ruben Smits wrote:
>
>> Ok, I just looked at orogen/master. Apparently a new dependency was
>> added: metaruby. Where do we need to fetch this dependency from, after
>> googling it seems that there are multiple different projects using this
>> name.
>> Should we add it as a submodule to the toolchain repository? Is it a
>> plain ruby package that we can easily install in a systempath?
>>
>>
> All your answers are in the autoproj build configuration (and in the email
> you sent to ask about metaruby on orocos-dev in september !)
>
> https://gitorious.org/orocos-toolchain/autoproj/source/
> ddb2eb137fd0b29c6930b9122282cbc4c29d58c0:source.yml
>
>
Ok, thanks, I'll give it a go.

Ruben

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

On Thu, Jan 2, 2014 at 11:12 AM, Ruben Smits
<ruben [dot] smits [..] ...>wrote:

>
>
>
> On Thu, Jan 2, 2014 at 10:56 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
>
>> On 01/02/2014 10:40 AM, Ruben Smits wrote:
>>
>>> Ok, I just looked at orogen/master. Apparently a new dependency was
>>> added: metaruby. Where do we need to fetch this dependency from, after
>>> googling it seems that there are multiple different projects using this
>>> name.
>>> Should we add it as a submodule to the toolchain repository? Is it a
>>> plain ruby package that we can easily install in a systempath?
>>>
>>>
>> All your answers are in the autoproj build configuration (and in the
>> email you sent to ask about metaruby on orocos-dev in september !)
>>
>> https://gitorious.org/orocos-toolchain/autoproj/source/
>> ddb2eb137fd0b29c6930b9122282cbc4c29d58c0:source.yml
>>
>>
> Ok, thanks, I'll give it a go.
>
>
I'm trying to build utilrb master and typelib master but keep on struggling
with system dependencies. I would like to pull all system dependencies as
debian packages (no gems).

How have you resolved the ruby1.9.3 dependency on Ubuntu 12.04? It seems
that is practically impossible to get all dependencies correctly from
debian packages without having to install ruby1.8 (it seems the rubygems
debian package is to blame).

The FindRuby.cmake file (the one provided in utilrb as well as the one
provided by cmake 2.8.12.1) is not able to detect ruby1.9.3 if ruby1.8 is
installed on the system.

Ruben

> Ruben
>
>
>>
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> 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
>> -----------------------------------------------------------------------
>>
>
>
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> This email and any attached files are confidential and may be legally
> privileged. Any copy, print or forward of this email, without the agreement
> of sender or addressee, is strictly prohibited. Misuse is a violation of
> the law on personal data protection (D. Lgs. 196/2003) and on secrecy of
> correspondence (art. 616 cp). If you have received this transmission in
> error please notify the sender immediately and then delete this email and
> any attached files.
>

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sun, 2014-02-09 08:38.

On 01/03/2014 10:30 AM, Ruben Smits wrote:
> How have you resolved the ruby1.9.3 dependency on Ubuntu 12.04? It seems
> that is practically impossible to get all dependencies correctly from
> debian packages without having to install ruby1.8 (it seems the rubygems
> debian package is to blame).
Not rubygems. Don't remember which one, but there is indeed a dependency
issue there. However, this is only installing a few useless packages,
not a big issue IMO (see below)

> The FindRuby.cmake file (the one provided in utilrb as well as the one
> provided by cmake 2.8.12.1) is not able to detect ruby1.9.3 if ruby1.8
> is installed on the system.
It is able to detect it, it only goes for the default ruby (the one
selected with update-alternatives) which is unfortunately either the
last installed or ruby 1.8 (don't remember). In any case, what the cmake
macros do make sense.

The autoproj configuration explicitly passes the ruby full path used to
bootstrap the installation to cmake as the RUBY_EXECUTABLE cmake
variable to make sure we use the right one regardless of everything
else. You should probably do the same.

catkin-related changes in orogen

Submitted by Ruben Smits on Sun, 2014-02-09 08:38.

On Mon, Jan 6, 2014 at 12:23 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/03/2014 10:30 AM, Ruben Smits wrote:
>
>> How have you resolved the ruby1.9.3 dependency on Ubuntu 12.04? It seems
>> that is practically impossible to get all dependencies correctly from
>> debian packages without having to install ruby1.8 (it seems the rubygems
>> debian package is to blame).
>>
> Not rubygems. Don't remember which one, but there is indeed a dependency
> issue there. However, this is only installing a few useless packages, not a
> big issue IMO (see below)
>
>
> The FindRuby.cmake file (the one provided in utilrb as well as the one
>> provided by cmake 2.8.12.1) is not able to detect ruby1.9.3 if ruby1.8
>> is installed on the system.
>>
> It is able to detect it, it only goes for the default ruby (the one
> selected with update-alternatives) which is unfortunately either the last
> installed or ruby 1.8 (don't remember). In any case, what the cmake macros
> do make sense.
>
>
I still think there is something wrong with the FindRuby.cmake, if i do
find_package(Ruby 1.9.3 REQUIRED) it is not able to find the correct ruby
executable if the default ruby is pointing to ruby1.8 (which is the default
if installed). I looks for executables named as ruby1.9 and ruby19, but the
actual executable is ruby1.9.1 or ruby1.9.3.

> The autoproj configuration explicitly passes the ruby full path used to
> bootstrap the installation to cmake as the RUBY_EXECUTABLE cmake variable
> to make sure we use the right one regardless of everything else. You should
> probably do the same.
>
>
Ok, I'll try that.

Maybe I should explain where I want to get at: creating debians for the
toolchain only based on debian-installed software. That's why I don't want
to depend on gems or other manual changes on the system.

Ruben

> --
> Sylvain Joyeux (Dr.Ing.)
> 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
> -----------------------------------------------------------------------
>

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sun, 2014-02-09 08:38.

On 01/06/2014 12:59 PM, Ruben Smits wrote:
> I still think there is something wrong with the FindRuby.cmake, if i do
> find_package(Ruby 1.9.3 REQUIRED) it is not able to find the correct
> ruby executable if the default ruby is pointing to ruby1.8 (which is the
> default if installed). I looks for executables named as ruby1.9 and
> ruby19, but the actual executable is ruby1.9.1 or ruby1.9.3.
This is definitely wrong ... It should at least bail out telling you it
got the wrong version.

Now, you should definitely NOT select the ruby version in the cmake
code. I start using 2.0 on debian, and try 2.1 out.

> The autoproj configuration explicitly passes the ruby full path used
> to bootstrap the installation to cmake as the RUBY_EXECUTABLE cmake
> variable to make sure we use the right one regardless of everything
> else. You should probably do the same.
>
>
> Ok, I'll try that.
>
> Maybe I should explain where I want to get at: creating debians for the
> toolchain only based on debian-installed software. That's why I don't
> want to depend on gems or other manual changes on the system.

The point of making gems (which we already did for you) is that there
*are* tools to convert gems to <insert binary package format here>, as
e.g. gem2deb.

It is therefore, as always, better to go for the standard (for cmake,
having a proper install target, for ruby, package as gems)... Other
people usually have done the rest of the work for you.

Which "manual changes" are you talking about here ?

catkin-related changes in orogen

Submitted by Ruben Smits on Sun, 2014-02-09 08:38.

On Mon, Jan 6, 2014 at 1:56 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/06/2014 12:59 PM, Ruben Smits wrote:
>
>> I still think there is something wrong with the FindRuby.cmake, if i do
>> find_package(Ruby 1.9.3 REQUIRED) it is not able to find the correct
>> ruby executable if the default ruby is pointing to ruby1.8 (which is the
>> default if installed). I looks for executables named as ruby1.9 and
>> ruby19, but the actual executable is ruby1.9.1 or ruby1.9.3.
>>
> This is definitely wrong ... It should at least bail out telling you it
> got the wrong version.
>

It did actually ...

>
> Now, you should definitely NOT select the ruby version in the cmake code.
> I start using 2.0 on debian, and try 2.1 out.

So the recommended way is to set the RUBY_EXECUTABLE?

>
>
> The autoproj configuration explicitly passes the ruby full path used
>> to bootstrap the installation to cmake as the RUBY_EXECUTABLE cmake
>> variable to make sure we use the right one regardless of everything
>> else. You should probably do the same.
>>
>>
>> Ok, I'll try that.
>>
>> Maybe I should explain where I want to get at: creating debians for the
>> toolchain only based on debian-installed software. That's why I don't
>> want to depend on gems or other manual changes on the system.
>>
>
> The point of making gems (which we already did for you) is that there
> *are* tools to convert gems to <insert binary package format here>, as e.g.
> gem2deb.
>
>
I'll look into this workflow asap.

> It is therefore, as always, better to go for the standard (for cmake,
> having a proper install target, for ruby, package as gems)... Other people
> usually have done the rest of the work for you.
>
> Which "manual changes" are you talking about here ?

I was talking about needing to use update-alternatives to set point ruby to
the correct version, but I assume using the RUBY_EXECUTABLE cmake variable
would solve this.

Ruben

catkin-related changes in orogen

Submitted by willy on Wed, 2014-02-12 12:20.

2014-01-06 Ruben Smits <ruben [dot] smits [..] ...>:

>
>
>
> On Mon, Jan 6, 2014 at 1:56 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
>
>> On 01/06/2014 12:59 PM, Ruben Smits wrote:
>>
>>> I still think there is something wrong with the FindRuby.cmake, if i do
>>> find_package(Ruby 1.9.3 REQUIRED) it is not able to find the correct
>>> ruby executable if the default ruby is pointing to ruby1.8 (which is the
>>> default if installed). I looks for executables named as ruby1.9 and
>>> ruby19, but the actual executable is ruby1.9.1 or ruby1.9.3.
>>>
>> This is definitely wrong ... It should at least bail out telling you it
>> got the wrong version.
>>
>
> It did actually ...
>
>
>>
>> Now, you should definitely NOT select the ruby version in the cmake code.
>> I start using 2.0 on debian, and try 2.1 out.
>
>
> So the recommended way is to set the RUBY_EXECUTABLE?
>
>
>>
>>
>> The autoproj configuration explicitly passes the ruby full path used
>>> to bootstrap the installation to cmake as the RUBY_EXECUTABLE cmake
>>> variable to make sure we use the right one regardless of everything
>>> else. You should probably do the same.
>>>
>>>
>>> Ok, I'll try that.
>>>
>>> Maybe I should explain where I want to get at: creating debians for the
>>> toolchain only based on debian-installed software. That's why I don't
>>> want to depend on gems or other manual changes on the system.
>>>
>>
>> The point of making gems (which we already did for you) is that there
>> *are* tools to convert gems to <insert binary package format here>, as e.g.
>> gem2deb.
>>
>>
> I'll look into this workflow asap.
>
>
>> It is therefore, as always, better to go for the standard (for cmake,
>> having a proper install target, for ruby, package as gems)... Other people
>> usually have done the rest of the work for you.
>>
>> Which "manual changes" are you talking about here ?
>
>
> I was talking about needing to use update-alternatives to set point ruby
> to the correct version, but I assume using the RUBY_EXECUTABLE cmake
> variable would solve this.
>
>
> Ruben
>
>>
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> 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
>> -----------------------------------------------------------------------
>>
>
>
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> This email and any attached files are confidential and may be legally
> privileged. Any copy, print or forward of this email, without the agreement
> of sender or addressee, is strictly prohibited. Misuse is a violation of
> the law on personal data protection (D. Lgs. 196/2003) and on secrecy of
> correspondence (art. 616 cp). If you have received this transmission in
> error please notify the sender immediately and then delete this email and
> any attached files.
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

Hi,

I'm trying to update my ros/orocos workspace with the information from here
:
https://github.com/orocos/rtt_ros_integration/blob/hydro-devel/README.md
And orogen is not detecting my ruby version (I'm on debian jessie).

Is the documentation up to date ? should I select a particular version of
ruby ?

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 01/02/2014 11:12 AM, Ruben Smits wrote:
> Ok, thanks, I'll give it a go.

FYI, to support binary packaging in Rock, we go for:
- all CMake packages are standard CMake packages, that is they can be
packaged with using the cmake common handler in cdbs
- all Ruby packages should be packaged as gems and then as debian
packages using gem2deb. (This is easiest as other repositories have
equivalents to gem2deb)

catkin-related changes in orogen

Submitted by Ruben Smits on Sat, 2014-01-04 20:32.

Hi Sylvain,

On Thu, Jan 2, 2014 at 11:15 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 01/02/2014 11:12 AM, Ruben Smits wrote:
>
>> Ok, thanks, I'll give it a go.
>>
>
> FYI, to support binary packaging in Rock, we go for:
> - all CMake packages are standard CMake packages, that is they can be
> packaged with using the cmake common handler in cdbs
> - all Ruby packages should be packaged as gems and then as debian
> packages using gem2deb. (This is easiest as other repositories have
> equivalents to gem2deb)
>
>
Thanks for this info, do you already provide debian packages for the ruby
packages somewhere? Can you provide me some information on how gems are
created or is there already something in-place to do this for utilrb/orogen?

Ruben

catkin-related changes in orogen

Submitted by Sylvain Joyeux on Sat, 2014-01-04 20:32.

On 01/02/2014 11:19 AM, Ruben Smits wrote:
> Thanks for this info, do you already provide debian packages for the
> ruby packages somewhere? Can you provide me some information on how gems
> are created or is there already something in-place to do this for
> utilrb/orogen?
>
I'm not the one that did it, so I only have partial information.

The relevant piece of code is the package_ruby method in

https://gitorious.org/rock/admin_scripts/source/3a1d10f2ecb96f3ecc734465...

In general, it seems that it runs rake gem and then some custom-made
code based on gem2tgz (which is part of gem2deb). We don't use gem2deb
as we want to be able to patch the debian/ directory if needed.

The resulting debian source is here:

https://build.opensuse.org/package/show/home:roehr:rock-robotics/ruby-or...

For orogen, it is functional since some orogen packages could be
successfully built by the OBS. But we have not found the time to test
the runtime part of these OBS-built orogen packages yet AFAIK.