Omniorb merge vs OS-X port

I've been looking at Sylvain's Omniorb branch again and apart from very minor
conflicts, it merges with the main line. I also fixed the remaining issues I had
earlier about the contributed code. The only thing I can't test is if the Mac
OS-X changes survived Sylvain's gentle though thorough merging capabilities.

Are the Mac OS-X folks fine with the merge on trunk and check how it goes ?

The alternative is to checkout Sylvain's tree on a Mac and apply the patches
in attachment :

git clone git://github.com/doudou/orocos-rtt.git
cd orocos-rtt
patch -p1 < ../*.patch

(Is there a git on OS-X ?)

Peter

AttachmentSize
0001-Fix-minor-compilation-build-system-errors-after-omni.patch1.45 KB
0002-Improved-CORBA-compilation-by-not-requiring-DCORBA_.patch12 KB

Omniorb merge vs OS-X port

On Saturday 31 January 2009 23:47:33 Peter Soetens wrote:
> I've been looking at Sylvain's Omniorb branch again and apart from very
> minor conflicts, it merges with the main line. I also fixed the remaining
> issues I had earlier about the contributed code. The only thing I can't
> test is if the Mac OS-X changes survived Sylvain's gentle though thorough
> merging capabilities.

In the end, I succeeded to rebase Sylvain's master code on the current head
and apply it on my master branch. However, his master contains three series of
patches:

* Omniorb
* datasource peeking
* File/IRQ Activities

Of these, only omniorb is applied. I'm hoping that the 'data source peeking'
won't be necessary once the new_data_ports branch matures (ie compiles :-)

And these misc patches
* rtt: define some other useful types in the default toolkit
* rtt: make CompletionProcessor a publicly usable class

I don't know what the purpose of the last one is (in which use case?) Is it
used ? The first one is acceptable.

This results in a kind-of cherry picking, but since I take only isolated
parts, I hope I don't screw the rebase process for Sylvain (he'll need to 'git
rebase --skip' a lot). Anyway, they're going in, I want 1.8.0 out.

Peter

Omniorb merge vs OS-X port

On Feb 5, 2009, at 08:03 , Peter Soetens wrote:

> On Saturday 31 January 2009 23:47:33 Peter Soetens wrote:
>> I've been looking at Sylvain's Omniorb branch again and apart from
>> very
>> minor conflicts, it merges with the main line. I also fixed the
>> remaining
>> issues I had earlier about the contributed code. The only thing I
>> can't
>> test is if the Mac OS-X changes survived Sylvain's gentle though
>> thorough
>> merging capabilities.
>
> In the end, I succeeded to rebase Sylvain's master code on the
> current head
> and apply it on my master branch. However, his master contains three
> series of
> patches:
>
> * Omniorb
> * datasource peeking
> * File/IRQ Activities
>
> Of these, only omniorb is applied. I'm hoping that the 'data source
> peeking'
> won't be necessary once the new_data_ports branch matures (ie
> compiles :-)
>
> And these misc patches
> * rtt: define some other useful types in the default toolkit
> * rtt: make CompletionProcessor a publicly usable class
>
> I don't know what the purpose of the last one is (in which use
> case?) Is it
> used ? The first one is acceptable.
>
> This results in a kind-of cherry picking, but since I take only
> isolated
> parts, I hope I don't screw the rebase process for Sylvain (he'll
> need to 'git
> rebase --skip' a lot). Anyway, they're going in, I want 1.8.0 out.

This is only available via git right now?

Once I figure out how to get it, I'll try it on one of my OS X machines.
S

Omniorb merge vs OS-X port

On Thursday 05 February 2009 14:14:01 S Roderick wrote:
> >
> > This results in a kind-of cherry picking, but since I take only
> > isolated
> > parts, I hope I don't screw the rebase process for Sylvain (he'll
> > need to 'git
> > rebase --skip' a lot). Anyway, they're going in, I want 1.8.0 out.
>
> This is only available via git right now?

I was in the process :-) It's now on SVN trunk and on git master. I'm glad to
see that at least authorship (who wrote which patch) is now also recorded.

Peter

Omniorb merge vs OS-X port

On Feb 5, 2009, at 08:40 , Peter Soetens wrote:

> On Thursday 05 February 2009 14:14:01 S Roderick wrote:
>>>
>>> This results in a kind-of cherry picking, but since I take only
>>> isolated
>>> parts, I hope I don't screw the rebase process for Sylvain (he'll
>>> need to 'git
>>> rebase --skip' a lot). Anyway, they're going in, I want 1.8.0 out.
>>
>> This is only available via git right now?
>
> I was in the process :-) It's now on SVN trunk and on git master.
> I'm glad to
> see that at least authorship (who wrote which patch) is now also
> recorded.
>
> Peter

Oh and KDL trunk is also broken as the transport-plugin patch has been
applied to RTT but not to KDL.
S

Omniorb merge vs OS-X port

As a general note, the build system of RTT is really in a need of cleanup.

What I tried to do for CORBA is to set corba-specific variables (CORBA_*) in the discovery scripts (i.e. FindOmniORB and FindTAO) and use those variables in the right CMakeLists files. This really should be a rule of thumb for writing CMake code as it removes the bunch of side-effects that currently exist in the configuration process.


Moreover, I'd feel much better if each external dependency would have its own Find*.cmake script instead of the generic overly complex check_* script.

Finally, there is more complete (and tested) scripts for dependencies like boost, maybe we should use it.


Sylvain

Omniorb merge vs OS-X port

On Feb 6, 2009, at 01:47 , Sylvain Joyeux wrote:

> As a general note, the build system of RTT is really in a need of
> cleanup.

Agreed.

> What I tried to do for CORBA is to set corba-specific variables
> (CORBA_*) in the discovery scripts (i.e. FindOmniORB and FindTAO)
> and use those variables in the right CMakeLists files. This really
> should be a rule of thumb for writing CMake code as it removes the
> bunch of side-effects that currently exist in the configuration
> process.
>
> Moreover, I'd feel much better if each external dependency would
> have its own Find*.cmake script instead of the generic overly
> complex check_* script.

The CMake recommended approach is a Find*.cmake and an (optional)
Use*.cmake for each dependancy. Personally I find that this approach
works really well, though some of the default CMake scripts need work
(eg UseSWIG is useless on the Mac). There has been some cleanup of our
CMake code over the past few months, and these kind of changes have
been worked in.

Some pages on writing Find*.cmake files

http://www.cmake.org/Wiki/CMake_HowToFindInstalledSoftware
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries ** though
does wrap some CMake stuff

> Finally, there is more complete (and tested) scripts for
> dependencies like boost, maybe we should use it.

I haven't looked at it, but sounds like a good idea.
S

Omniorb merge vs OS-X port

On Feb 5, 2009, at 08:40 , Peter Soetens wrote:

> On Thursday 05 February 2009 14:14:01 S Roderick wrote:
>>>
>>> This results in a kind-of cherry picking, but since I take only
>>> isolated
>>> parts, I hope I don't screw the rebase process for Sylvain (he'll
>>> need to 'git
>>> rebase --skip' a lot). Anyway, they're going in, I want 1.8.0 out.
>>
>> This is only available via git right now?
>
> I was in the process :-) It's now on SVN trunk and on git master.
> I'm glad to
> see that at least authorship (who wrote which patch) is now also
> recorded.
>
> Peter

Sorry, but trunk with omniorb is broken. :-((

You can't reset RTT_CFLAGS at the start of config/global_setup.cmake
as it's already been set to something useful in config/
check_depend.cmake. Only noticeable if you have boost in a non-
standard install dir, or are running RTAI, Xenomai or ecos.

Someone put "-Wno-deprecated" into RTT_CFLAGS (also, it should have
been added and not blanketly assigned). This causes warnings on .c
files, as gcc says it is C++ only. We can't add this to RTT_CXXFLAGS
as that really isn't used. Rock <--> Us <--> Hard place. What
now?

The corba-test seg faults, apparently on InitOrb(). Weird! This is a
default install of OminORB from MacPorts v1.7. Does this with or
without a naming service environment variable.

Baby steps ... baby steps ...

Cheers
S

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Omniorb merge vs OS-X port

On Friday 06 February 2009 02:54:29 Stephen Roderick wrote:
>
> Sorry, but trunk with omniorb is broken. :-((
>
> You can't reset RTT_CFLAGS at the start of config/global_setup.cmake
> as it's already been set to something useful in config/
> check_depend.cmake. Only noticeable if you have boost in a non-
> standard install dir, or are running RTAI, Xenomai or ecos.

Ouch. We still need to reset RTT_CFLAGS somewhere, otherwise, it will just
cumulate flags every cmake run due to
SET(RTT_CFLAGS "${RTT_CFLAGS} -I${XENOMAI_INCLUDE_DIR}" CACHE INTERNAL "")
in config/check_depend.cmake

>
> Someone put "-Wno-deprecated" into RTT_CFLAGS (also, it should have
> been added and not blanketly assigned). This causes warnings on .c
> files, as gcc says it is C++ only. We can't add this to RTT_CXXFLAGS
> as that really isn't used. Rock <--> Us <--> Hard place. What
> now?

Remove it again until we got something better. So this goes out again:

diff --git a/config/global_setup.cmake b/config/global_setup.cmake
index 207d615..bfe66c6 100644
--- a/config/global_setup.cmake
+++ b/config/global_setup.cmake
@@ -15,7 +15,7 @@ MESSAGE("CMAKE_VERSION: ${CMAKE_VERSION}")
 #
 # If we're using gcc, make sure the version is OK.
 #
-SET(RTT_CXXFLAGS "")
+SET(RTT_CFLAGS "")
 # this is a workaround distcc:
 IF ( CMAKE_CXX_COMPILER_ARG1 )
   STRING(REPLACE " " "" CMAKE_CXX_COMPILER_ARG1 ${CMAKE_CXX_COMPILER_ARG1} )
@@ -30,7 +30,7 @@ IF ( ${CXX_HAS_VERSION} EQUAL 0 )
   # We are assuming here that -dumpversion is gcc specific.
   IF( CXX_VERSION MATCHES "4\\.[0-9](\\.[0-9])?" )
     MESSAGE("Detected gcc4: ${CXX_VERSION}")
-    #SET(RTT_CXXFLAGS "-fvisibility-inlines-hidden")
+    SET(RTT_CFLAGS "-Wno-deprecated")
     SET(RTT_GCC_HASVISIBILITY TRUE)
   ELSE(CXX_VERSION MATCHES "4\\.[0-9](\\.[0-9])?")
     IF( CXX_VERSION MATCHES "3\\.[0-9](\\.[0-9])?" )

>
> The corba-test seg faults, apparently on InitOrb(). Weird! This is a
> default install of OminORB from MacPorts v1.7. Does this with or
> without a naming service environment variable.

The unit tests passed for both Omniorb and TAO on my gnulinux system

Peter

Omniorb merge vs OS-X port

On Feb 6, 2009, at 06:55 , Peter Soetens wrote:

> On Friday 06 February 2009 02:54:29 Stephen Roderick wrote:
>>
>> Sorry, but trunk with omniorb is broken. :-((
>>
>> You can't reset RTT_CFLAGS at the start of config/global_setup.cmake
>> as it's already been set to something useful in config/
>> check_depend.cmake. Only noticeable if you have boost in a non-
>> standard install dir, or are running RTAI, Xenomai or ecos.
>
> Ouch. We still need to reset RTT_CFLAGS somewhere, otherwise, it
> will just
> cumulate flags every cmake run due to
> SET(RTT_CFLAGS "${RTT_CFLAGS} -I${XENOMAI_INCLUDE_DIR}" CACHE
> INTERNAL "")
> in config/check_depend.cmake

Understood.

>> Someone put "-Wno-deprecated" into RTT_CFLAGS (also, it should have
>> been added and not blanketly assigned). This causes warnings on .c
>> files, as gcc says it is C++ only. We can't add this to RTT_CXXFLAGS
>> as that really isn't used. Rock <--> Us <--> Hard place. What
>> now?
>
> Remove it again until we got something better. So this goes out again:
>

> diff --git a/config/global_setup.cmake b/config/global_setup.cmake
> index 207d615..bfe66c6 100644
> --- a/config/global_setup.cmake
> +++ b/config/global_setup.cmake
> @@ -15,7 +15,7 @@ MESSAGE("CMAKE_VERSION: ${CMAKE_VERSION}")
> #
> # If we're using gcc, make sure the version is OK.
> #
> -SET(RTT_CXXFLAGS "")
> +SET(RTT_CFLAGS "")
 
NO! If you want to do this it has to be done before *both*  
global_setup.cmake and check_depend.cmake.
 
>> The corba-test seg faults, apparently on InitOrb(). Weird! This is a
>> default install of OminORB from MacPorts v1.7. Does this with or
>> without a naming service environment variable.
>
> The unit tests passed for both Omniorb and TAO on my gnulinux system
 
With TAO they passed on my system recently, though I have yet to try  
with up to date trunk.
S

Omniorb merge vs OS-X port

On Friday 06 February 2009 14:21:15 Stephen Roderick wrote:
> On Feb 6, 2009, at 06:55 , Peter Soetens wrote:
> > On Friday 06 February 2009 02:54:29 Stephen Roderick wrote:
> >> Sorry, but trunk with omniorb is broken. :-((
> >>
> >> You can't reset RTT_CFLAGS at the start of config/global_setup.cmake
> >> as it's already been set to something useful in config/
> >> check_depend.cmake. Only noticeable if you have boost in a non-
> >> standard install dir, or are running RTAI, Xenomai or ecos.
> >
> > Ouch. We still need to reset RTT_CFLAGS somewhere, otherwise, it
> > will just
> > cumulate flags every cmake run due to
> > SET(RTT_CFLAGS "${RTT_CFLAGS} -I${XENOMAI_INCLUDE_DIR}" CACHE
> > INTERNAL "")
> > in config/check_depend.cmake
>
> Understood.
>
> >> Someone put "-Wno-deprecated" into RTT_CFLAGS (also, it should have
> >> been added and not blanketly assigned). This causes warnings on .c
> >> files, as gcc says it is C++ only. We can't add this to RTT_CXXFLAGS
> >> as that really isn't used. Rock <--> Us <--> Hard place. What
> >> now?
> >
> > Remove it again until we got something better. So this goes out again:
> >

> > diff --git a/config/global_setup.cmake b/config/global_setup.cmake
> > index 207d615..bfe66c6 100644
> > --- a/config/global_setup.cmake
> > +++ b/config/global_setup.cmake
> > @@ -15,7 +15,7 @@ MESSAGE("CMAKE_VERSION: ${CMAKE_VERSION}")
> > #
> > # If we're using gcc, make sure the version is OK.
> > #
> > -SET(RTT_CXXFLAGS "")
> > +SET(RTT_CFLAGS "")
>
> NO! If you want to do this it has to be done before *both*
> global_setup.cmake and check_depend.cmake.
 
I know. I just wanted to point out that the patch listed above is reverted, so 
you need to read the + as - and vice verse :-] See the svn commit log.
 
I still have to set RTT_CFLAGS to "" before 'anything'.
 
Peter

Omniorb merge vs OS-X port

On Saturday 31 January 2009 23:47:33 Peter Soetens wrote:
> I've been looking at Sylvain's Omniorb branch again and apart from very
> minor conflicts, it merges with the main line. I also fixed the remaining
> issues I had earlier about the contributed code. The only thing I can't
> test is if the Mac OS-X changes survived Sylvain's gentle though thorough
> merging capabilities.

>
> Are the Mac OS-X folks fine with the merge on trunk and check how it goes ?

>
> The alternative is to checkout Sylvain's tree on a Mac and apply the
> patches in attachment :
>
> git clone git://github.com/doudou/orocos-rtt.git
> cd orocos-rtt
> patch -p1 < ../*.patch
>
> (Is there a git on OS-X ?)
>
> Peter