On Thursday 25 September 2008 19:10:50 Sylvain Joyeux wrote:
> The main aim of this bunch of patches is the ability to use OmniORB4 in
> Orocos -- instead of TAO. TAO is huge, slow and very hard to
> hand-compile (which sometime is something you have to do). Given that
> people I know and trust are using OmniORB for robotic applications, I
> wanted to give it a try.
>
> The first patches (17-20) are actually generic fixes in the way the CORBA
> code handles the 'nil' value (which is NULL on TAO, but does not have to
> be).
>
> The second part (21-26) is really getting into the subject, making OmniORB
> a compile-time option. I hope I broke nothing of the MacOS-X fixes that
> came lately.

That was more in the build system than any other place, so I don't expect
problems except there.

OmniORB support is very welcome as a 1.8.0 feature. I'll review and apply
asap.

Peter

On Thursday 25 September 2008 19:10:50 Sylvain Joyeux wrote:
> The main aim of this bunch of patches is the ability to use OmniORB4 in
> Orocos -- instead of TAO. TAO is huge, slow and very hard to
> hand-compile (which sometime is something you have to do). Given that
> people I know and trust are using OmniORB for robotic applications, I
> wanted to give it a try.
>
> The first patches (17-20) are actually generic fixes in the way the CORBA
> code handles the 'nil' value (which is NULL on TAO, but does not have to
> be).
>
> The second part (21-26) is really getting into the subject, making OmniORB
> a compile-time option. I hope I broke nothing of the MacOS-X fixes that
> came lately.

I tried to apply these patches on my local git repository (with git-am), but
the whitespace changes are preventing them to apply. I tried to use

git-am -i --whitespace=fix ~/Mail/Orocos-patches.mbox

but I still get the same errors, while the patches apply mostly fine when
using patch -p1 -l on the raw patches.

Could you fix this locally and re-submit or do you know a better way to handle
whitespace changes ?

Peter