orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 10:14

Orocos-users

Dear list,

disclaimer: I've only just started using orocos, so apologies if this is common knowledge.

To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.

Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?

Is the described workflow for changing targets 'the' way to do it, or are there better ways?

thanks,

orocos_toolchain: working with multiple targets

Submitted by peter on Mon, 2012-04-02 12:36.

2012/4/2 g a <gaohml [..] ...>:
>
> Dear list,
>
> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>
> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>
> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>
> Is the described workflow for changing targets 'the' way to do it, or are there better ways?

You only need to set OROCOS_TARGET to a different target and do a
'rosmake' again. There's no need to have separate install dirs or
modify the ROS_PACKAGE_PATH. The only tool which does not yet support
this workflow is typegen/orogen in case you would want to use these
tools too.

Peter

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 13:04.

Peter Soetens wrote:
> 2012/4/2 g a <gaohml [..] ...>:
>> Dear list,
>>
>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>
>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>
>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>
>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>
> You only need to set OROCOS_TARGET to a different target and do a
> 'rosmake' again. There's no need to have separate install dirs or
> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
> this workflow is typegen/orogen in case you would want to use these
> tools too.

ok, thank you.

What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.

orocos_toolchain: working with multiple targets

Submitted by peter on Mon, 2012-04-02 13:16.

2012/4/2 g ah <gaohml [..] ...>:
>
> Peter Soetens wrote:
>> 2012/4/2 g a <gaohml [..] ...>:
>>> Dear list,
>>>
>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>
>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>
>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>
>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>
>> You only need to set OROCOS_TARGET to a different target and do a
>> 'rosmake' again. There's no need to have separate install dirs or
>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>> this workflow is typegen/orogen in case you would want to use these
>> tools too.
>
> ok, thank you.
>
> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>

It will crash :-(

orogen/typegen caches the target and will link your gnulinux typekits
with xenomai libraries or vice versa.

One workaround is to rm -rf the build/ directory in these typekit
packages before you change the OROCOS_TARGET.
Another workaround is to adapt the typegen cmake logic to use the
${OROCOS_TARGET} in the cmake variable names that are target
dependent.

Peter

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 14:24.

Peter Soetens wrote:
> 2012/4/2 g ah :
>> Peter Soetens wrote:
>>> 2012/4/2 g a :
>>>> Dear list,
>>>>
>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>
>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>
>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>
>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>> You only need to set OROCOS_TARGET to a different target and do a
>>> 'rosmake' again. There's no need to have separate install dirs or
>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>> this workflow is typegen/orogen in case you would want to use these
>>> tools too.
>> ok, thank you.
>>
>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>
>
> It will crash :-(
>
> orogen/typegen caches the target and will link your gnulinux typekits
> with xenomai libraries or vice versa.
>
> One workaround is to rm -rf the build/ directory in these typekit
> packages before you change the OROCOS_TARGET.
> Another workaround is to adapt the typegen cmake logic to use the
> ${OROCOS_TARGET} in the cmake variable names that are target
> dependent.

hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?

I compiled the targets with:

OROCOS_TARGET=xenomai rosmake orocos_toolchain
OROCOS_TARGET=gnulinux rosmake orocos_toolchain

ldd deployer-gnulinux now shows:

liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
...
librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0

and consequently 'libxenomai.so', 'libpthread_rt.so' etc.

Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)

thanks,

orocos_toolchain: working with multiple targets

Submitted by peter on Mon, 2012-04-02 14:48.

2012/4/2 g ah <gaohml [..] ...>:
>
>
> Peter Soetens wrote:
>> 2012/4/2 g ah :
>>> Peter Soetens wrote:
>>>> 2012/4/2 g a :
>>>>> Dear list,
>>>>>
>>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>>
>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>>
>>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>>
>>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>>> this workflow is typegen/orogen in case you would want to use these
>>>> tools too.
>>> ok, thank you.
>>>
>>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>>
>>
>> It will crash :-(
>>
>> orogen/typegen caches the target and will link your gnulinux typekits
>> with xenomai libraries or vice versa.
>>
>> One workaround is to rm -rf the build/ directory in these typekit
>> packages before you change the OROCOS_TARGET.
>> Another workaround is to adapt the typegen cmake logic to use the
>> ${OROCOS_TARGET} in the cmake variable names that are target
>> dependent.
>
> hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?
>
> I compiled the targets with:
>
> OROCOS_TARGET=xenomai rosmake orocos_toolchain
> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>
> ldd deployer-gnulinux now shows:
>
> liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
> liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
> ...
> librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
> librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>
> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.

Grr... please submit a bug report. It seems even OCL is not fully
supporting this feature either. The cmake macros
(ocl/config/FindRTTPlugin.cmake) bringing in marshalling & scripting
are somehow not adapted yet

>
>
> Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)
>
> thanks,

Willy was refering to 'ccache' a tool which caches your .o files such
that a second time, they are not rebuilt by your compiler.

Peter

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 16:04.

Peter Soetens wrote:
> 2012/4/2 g ah <gaohml [..] ...>:
>>
>> Peter Soetens wrote:
>>> 2012/4/2 g ah :
>>>> Peter Soetens wrote:
>>>>> 2012/4/2 g a :
>>>>>> Dear list,
>>>>>>
>>>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>>>
>>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>>>
>>>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>>>
>>>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>>>> this workflow is typegen/orogen in case you would want to use these
>>>>> tools too.
>>>> ok, thank you.
>>>>
>>>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>>>
>>> It will crash :-(
>>>
>>> orogen/typegen caches the target and will link your gnulinux typekits
>>> with xenomai libraries or vice versa.
>>>
>>> One workaround is to rm -rf the build/ directory in these typekit
>>> packages before you change the OROCOS_TARGET.
>>> Another workaround is to adapt the typegen cmake logic to use the
>>> ${OROCOS_TARGET} in the cmake variable names that are target
>>> dependent.
>> hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?
>>
>> I compiled the targets with:
>>
>> OROCOS_TARGET=xenomai rosmake orocos_toolchain
>> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>>
>> ldd deployer-gnulinux now shows:
>>
>> liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
>> liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
>> ...
>> librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
>> librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>>
>> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.
>
> Grr... please submit a bug report. It seems even OCL is not fully
> supporting this feature either. The cmake macros
> (ocl/config/FindRTTPlugin.cmake) bringing in marshalling & scripting
> are somehow not adapted yet

Done. See http://bugs.orocos.org/show_bug.cgi?id=936.

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 15:24.

ah, ok. Back to two directories for now then.

I'll see about the bug report. Do I need another account for that? I tried to register yesterday for the forum, but haven't received a reply yet.

>> Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)
>>
>> thanks,
>
> Willy was refering to 'ccache' a tool which caches your .o files such
> that a second time, they are not rebuilt by your compiler.

yes that makes more sense.

thank you,

orocos_toolchain: working with multiple targets

Submitted by willy on Mon, 2012-04-02 14:32.

I highly suggest that you setup a ccake environnement if not already
done. It takes very few time to do and it'll save you so much time
with Orocos.
I am not sure if many people are using xenomai with a 2.X version of
Orocos or/and with a 2.6 version of xenomai... you migth be opening
the path.

> thanks,
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 14:40.

Willy Lambert wrote:
> 2012/4/2 g ah <gaohml [..] ...>:
>> Peter Soetens wrote:
>>> 2012/4/2 g ah :
>>>> Peter Soetens wrote:
>>>>> 2012/4/2 g a :
>>>>>> Dear list,
>>>>>>
>>>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>>>
>>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>>>
>>>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>>>
>>>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>>>> this workflow is typegen/orogen in case you would want to use these
>>>>> tools too.
>>>> ok, thank you.
>>>>
>>>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>>>
>>> It will crash :-(
>>>
>>> orogen/typegen caches the target and will link your gnulinux typekits
>>> with xenomai libraries or vice versa.
>>>
>>> One workaround is to rm -rf the build/ directory in these typekit
>>> packages before you change the OROCOS_TARGET.
>>> Another workaround is to adapt the typegen cmake logic to use the
>>> ${OROCOS_TARGET} in the cmake variable names that are target
>>> dependent.
>> hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?
>>
>> I compiled the targets with:
>>
>> OROCOS_TARGET=xenomai rosmake orocos_toolchain
>> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>>
>> ldd deployer-gnulinux now shows:
>>
>> liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
>> liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
>> ...
>> librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
>> librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>>
>> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.
>>
>>
>> Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)
>>
>
> I highly suggest that you setup a ccake environnement if not already
> done. It takes very few time to do and it'll save you so much time
> with Orocos.
> I am not sure if many people are using xenomai with a 2.X version of
> Orocos or/and with a 2.6 version of xenomai... you migth be opening
> the path.

As far as I understood the documentation, compiling with or without ros(make) should not make a difference?

If I understand you correctly, you are suggesting to do a 'from source' install of orocos but without the ros infrastructure (so using autoproj)?

PS: I encountered the issue I reported on in the other mail (warn_upon_switch ..) before I tried a combined orocos_toolchain setup.

orocos_toolchain: working with multiple targets

Submitted by willy on Mon, 2012-04-02 14:48.

2012/4/2 g ah <gaohml [..] ...>:
>
> Willy Lambert wrote:
>> 2012/4/2 g ah <gaohml [..] ...>:
>>> Peter Soetens wrote:
>>>> 2012/4/2 g ah :
>>>>> Peter Soetens wrote:
>>>>>> 2012/4/2 g a :
>>>>>>> Dear list,
>>>>>>>
>>>>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>>>>
>>>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>>>>
>>>>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>>>>
>>>>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>>>>> this workflow is typegen/orogen in case you would want to use these
>>>>>> tools too.
>>>>> ok, thank you.
>>>>>
>>>>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>>>>
>>>> It will crash :-(
>>>>
>>>> orogen/typegen caches the target and will link your gnulinux typekits
>>>> with xenomai libraries or vice versa.
>>>>
>>>> One workaround is to rm -rf the build/ directory in these typekit
>>>> packages before you change the OROCOS_TARGET.
>>>> Another workaround is to adapt the typegen cmake logic to use the
>>>> ${OROCOS_TARGET} in the cmake variable names that are target
>>>> dependent.
>>> hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?
>>>
>>> I compiled the targets with:
>>>
>>> OROCOS_TARGET=xenomai rosmake orocos_toolchain
>>> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>>>
>>> ldd deployer-gnulinux now shows:
>>>
>>> liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
>>> liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
>>> ...
>>> librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
>>> librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>>>
>>> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.
>>>
>>>
>>> Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)
>>>
>>
>> I highly suggest that you setup a ccake environnement if not already
>> done. It takes very few time to do and it'll save you so much time
>> with Orocos.
>> I am not sure if many people are using xenomai with a 2.X version of
>> Orocos or/and with a 2.6 version of xenomai... you migth be opening
>> the path.
>
> As far as I understood the documentation, compiling with or without ros(make) should not make a difference?
>
> If I understand you correctly, you are suggesting to do a 'from source' install of orocos but without the ros infrastructure (so using autoproj)?
>

no no. this don't change anything. I am just speaking about ccache but
i did write shit in last post ^^
http://ccache.samba.org/

In a standard linux it means apt-get install ccache and creating
symbolic links to gcc/g++/.. added in path first and a cache file
somewhere (you need 1 or 2G).

>
>
> PS: I encountered the issue I reported on in the other mail (warn_upon_switch ..) before I tried a combined orocos_toolchain setup.
>

orocos_toolchain: working with multiple targets

Submitted by gah on Mon, 2012-04-02 20:44.

Willy Lambert wrote:
> 2012/4/2 g ah <gaohml [..] ...>:
>> Willy Lambert wrote:
>>> 2012/4/2 g ah <gaohml [..] ...>:
>>>> Peter Soetens wrote:
>>>>> 2012/4/2 g ah :
>>>>>> Peter Soetens wrote:
>>>>>>> 2012/4/2 g a :
>>>>>>>> Dear list,
>>>>>>>>
>>>>>>>> disclaimer: I've only just started using orocos, so apologies if this is common knowledge.
>>>>>>>>
>>>>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN variable.
>>>>>>>>
>>>>>>>> Is there any way to 'combine' multiple targets into one 'install' dir in orocos_toolchain in ROS? Or does this overwrite headers / configuration files in an incompatible way?
>>>>>>>>
>>>>>>>> Is the described workflow for changing targets 'the' way to do it, or are there better ways?
>>>>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet support
>>>>>>> this workflow is typegen/orogen in case you would want to use these
>>>>>>> tools too.
>>>>>> ok, thank you.
>>>>>>
>>>>>> What exactly is the consequence of the lack of support in typegen/orogen? At the moment I just add headers with type declarations to the 'orocos_typegen_headers' statement in CMakeLists.
>>>>>>
>>>>> It will crash :-(
>>>>>
>>>>> orogen/typegen caches the target and will link your gnulinux typekits
>>>>> with xenomai libraries or vice versa.
>>>>>
>>>>> One workaround is to rm -rf the build/ directory in these typekit
>>>>> packages before you change the OROCOS_TARGET.
>>>>> Another workaround is to adapt the typegen cmake logic to use the
>>>>> ${OROCOS_TARGET} in the cmake variable names that are target
>>>>> dependent.
>>>> hm, could this also explain why 'deployer-gnulinux' is now linked with the xenomai versions of rtt-marshalling and rtt-scripting?
>>>>
>>>> I compiled the targets with:
>>>>
>>>> OROCOS_TARGET=xenomai rosmake orocos_toolchain
>>>> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>>>>
>>>> ldd deployer-gnulinux now shows:
>>>>
>>>> liborocos-rtt-gnulinux.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
>>>> liborocos-rtt-xenomai.so.2.5 => /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
>>>> ...
>>>> librtt-marshalling-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
>>>> librtt-scripting-xenomai.so.2.5.0 => /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>>>>
>>>> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.
>>>>
>>>>
>>>> Apologies for asking the obvious, but I'd rather avoid recompiling orocos_toolchain a few more times :)
>>>>
>>> I highly suggest that you setup a ccake environnement if not already
>>> done. It takes very few time to do and it'll save you so much time
>>> with Orocos.
>>> I am not sure if many people are using xenomai with a 2.X version of
>>> Orocos or/and with a 2.6 version of xenomai... you migth be opening
>>> the path.
>> As far as I understood the documentation, compiling with or without ros(make) should not make a difference?
>>
>> If I understand you correctly, you are suggesting to do a 'from source' install of orocos but without the ros infrastructure (so using autoproj)?
>>
>
> no no. this don't change anything. I am just speaking about ccache but
> i did write shit in last post ^^
> http://ccache.samba.org/
>
> In a standard linux it means apt-get install ccache and creating
> symbolic links to gcc/g++/.. added in path first and a cache file
> somewhere (you need 1 or 2G).

I've installed ccache, but I don't observe a significant difference in compilation times. Max cache size is at 1GB, but a full compile of the toolchain (and rtt_*) results in only approx 900KB of cache use (and still takes about 30mins, even repeat builds). Current set up uses symlinks in '~/bin', which rosmake seems to be picking up.

Any pointers?

orocos_toolchain: working with multiple targets

Submitted by willy on Mon, 2012-04-02 20:48.

2012/4/2 g ah <gaohml [..] ...>:
> Willy Lambert wrote:
>> 2012/4/2 g ah <gaohml [..] ...>:
>>> Willy Lambert wrote:
>>>> 2012/4/2 g ah <gaohml [..] ...>:
>>>>> Peter Soetens wrote:
>>>>>> 2012/4/2 g ah :
>>>>>>> Peter Soetens wrote:
>>>>>>>> 2012/4/2 g a :
>>>>>>>>> Dear list,
>>>>>>>>>
>>>>>>>>> disclaimer: I've only just started using orocos, so apologies if
>>>>>>>>> this is common knowledge.
>>>>>>>>>
>>>>>>>>> To get Xenomai support in the orocos_toolchain in ROS, I've
>>>>>>>>> compiled orocos_toolchain from source setting OROCOS_TARGET=xenomai, which
>>>>>>>>> worked. To switch targets, I currently have to edit the ROS_PACKAGE_PATH
>>>>>>>>> (include the correct orocos_toolchain build) and update the OROCOS_TOOLCHAIN
>>>>>>>>> variable.
>>>>>>>>>
>>>>>>>>> Is there any way to 'combine' multiple targets into one 'install'
>>>>>>>>> dir in orocos_toolchain in ROS? Or does this overwrite headers /
>>>>>>>>> configuration files in an incompatible way?
>>>>>>>>>
>>>>>>>>> Is the described workflow for changing targets 'the' way to do it,
>>>>>>>>> or are there better ways?
>>>>>>>> You only need to set OROCOS_TARGET to a different target and do a
>>>>>>>> 'rosmake' again. There's no need to have separate install dirs or
>>>>>>>> modify the ROS_PACKAGE_PATH. The only tool which does not yet
>>>>>>>> support
>>>>>>>> this workflow is typegen/orogen in case you would want to use these
>>>>>>>> tools too.
>>>>>>> ok, thank you.
>>>>>>>
>>>>>>> What exactly is the consequence of the lack of support in
>>>>>>> typegen/orogen? At the moment I just add headers with type declarations to
>>>>>>> the 'orocos_typegen_headers' statement in CMakeLists.
>>>>>>>
>>>>>> It will crash :-(
>>>>>>
>>>>>> orogen/typegen caches the target and will link your gnulinux typekits
>>>>>> with xenomai libraries or vice versa.
>>>>>>
>>>>>> One workaround is to rm -rf the build/ directory in these typekit
>>>>>> packages before you change the OROCOS_TARGET.
>>>>>> Another workaround is to adapt the typegen cmake logic to use the
>>>>>> ${OROCOS_TARGET} in the cmake variable names that are target
>>>>>> dependent.
>>>>> hm, could this also explain why 'deployer-gnulinux' is now linked with
>>>>> the xenomai versions of rtt-marshalling and rtt-scripting?
>>>>>
>>>>> I compiled the targets with:
>>>>>
>>>>> OROCOS_TARGET=xenomai rosmake orocos_toolchain
>>>>> OROCOS_TARGET=gnulinux rosmake orocos_toolchain
>>>>>
>>>>> ldd deployer-gnulinux now shows:
>>>>>
>>>>> liborocos-rtt-gnulinux.so.2.5 =>
>>>>> /home/gah/.../install/lib/liborocos-rtt-gnulinux.so.2.5
>>>>> liborocos-rtt-xenomai.so.2.5 =>
>>>>> /home/gah/.../install/lib/liborocos-rtt-xenomai.so.2.5
>>>>> ...
>>>>> librtt-marshalling-xenomai.so.2.5.0 =>
>>>>> /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-marshalling-xenomai.so.2.5.0
>>>>> librtt-scripting-xenomai.so.2.5.0 =>
>>>>> /home/gah/.../install/lib/orocos/xenomai/plugins/librtt-scripting-xenomai.so.2.5.0
>>>>>
>>>>> and consequently 'libxenomai.so', 'libpthread_rt.so' etc.
>>>>>
>>>>>
>>>>> Apologies for asking the obvious, but I'd rather avoid recompiling
>>>>> orocos_toolchain a few more times :)
>>>>>
>>>> I highly suggest that you setup a ccake environnement if not already
>>>> done. It takes very few time to do and it'll save you so much time
>>>> with Orocos.
>>>> I am not sure if many people are using xenomai with a 2.X version of
>>>> Orocos or/and with a 2.6 version of xenomai... you migth be opening
>>>> the path.
>>> As far as I understood the documentation, compiling with or without
>>> ros(make) should not make a difference?
>>>
>>> If I understand you correctly, you are suggesting to do a 'from source'
>>> install of orocos but without the ros infrastructure (so using autoproj)?
>>>
>>
>> no no. this don't change anything. I am just speaking about ccache but
>> i did write shit in last post ^^
>> http://ccache.samba.org/
>>
>> In a standard linux it means apt-get install ccache and creating
>> symbolic links to gcc/g++/.. added in path first and a cache file
>> somewhere (you need 1 or 2G).
>
> I've installed ccache, but I don't observe a significant difference in
> compilation times. Max cache size is at 1GB, but a full compile of the
> toolchain (and rtt_*) results in only approx 900KB of cache use (and still
> takes about 30mins, even repeat builds). Current set up uses symlinks in
> '~/bin', which rosmake seems to be picking up.
>
> Any pointers?
>

"ccache -s" should show cache hits increasing during the build. If not
check your PATH env variable, you probably miss linked gcc/g++. It
must be at the beginning of it.

ccache with orocos_toolchain (was: RE: orocos_toolchain: working

Submitted by gah on Mon, 2012-04-02 21:00.

Willy Lambert wrote:
> 2012/4/2 g ah <gaohml [..] ...>:
>> Willy Lambert wrote:
[..]
>>> no no. this don't change anything. I am just speaking about ccache but
>>> i did write shit in last post ^^
>>> http://ccache.samba.org/
>>>
>>> In a standard linux it means apt-get install ccache and creating
>>> symbolic links to gcc/g++/.. added in path first and a cache file
>>> somewhere (you need 1 or 2G).
>> I've installed ccache, but I don't observe a significant difference in
>> compilation times. Max cache size is at 1GB, but a full compile of the
>> toolchain (and rtt_*) results in only approx 900KB of cache use (and still
>> takes about 30mins, even repeat builds). Current set up uses symlinks in
>> '~/bin', which rosmake seems to be picking up.
>>
>> Any pointers?
>
> "ccache -s" should show cache hits increasing during the build. If not
> check your PATH env variable, you probably miss linked gcc/g++. It
> must be at the beginning of it.

perhaps this is not the right mailing list to ask this. My path seems to be set up correctly (which g{cc,++} returns my symlinks), and the cache seems to be used ('ccache -s' indeed shows some stats).

I was just wondering what kind of speed up you were getting.

thanks,

ccache with orocos_toolchain (was: RE: orocos_toolchain: working

Submitted by peter on Mon, 2012-04-02 21:24.

2012/4/2 g ah <gaohml [..] ...>:
>
> Willy Lambert wrote:
>> 2012/4/2 g ah <gaohml [..] ...>:
>>> Willy Lambert wrote:
> [..]
>>>> no no. this don't change anything. I am just speaking about ccache but
>>>> i did write shit in last post ^^
>>>> http://ccache.samba.org/
>>>>
>>>> In a standard linux it means apt-get install ccache and creating
>>>> symbolic links to gcc/g++/.. added in path first and a cache file
>>>> somewhere (you need 1 or 2G).
>>> I've installed ccache, but I don't observe a significant difference in
>>> compilation times. Max cache size is at 1GB, but a full compile of the
>>> toolchain (and rtt_*) results in only approx 900KB of cache use (and still
>>> takes about 30mins, even repeat builds). Current set up uses symlinks in
>>> '~/bin', which rosmake seems to be picking up.
>>>
>>> Any pointers?
>>
>> "ccache -s" should show cache hits increasing during the build. If not
>> check your PATH env variable, you probably miss linked gcc/g++. It
>> must be at the beginning of it.
>
> perhaps this is not the right mailing list to ask this. My path seems to be set up correctly (which g{cc,++} returns my symlinks), and the cache seems to be used ('ccache -s' indeed shows some stats).
>
> I was just wondering what kind of speed up you were getting.

Recompilation speeds take seconds instead of 10s of minutes. What
might be with your setup is that CMake has cached /usr/bin/g++ already
as the compiler instead of your new path. You'll have to rm -rf your
build directories (or remove CMakeCache.txt) in order to use the
ccache compiler. I typically have this on Ubuntu in /etc/environment:

PATH="/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"

but you could add such a path statement in your .bashrc too.

Peter