[omniORB] I Want to Port OmniORB to NetBSD

[Duncan Grisby]

On Wednesday 9 April, "Zed A. Shaw" wrote:

> I'm the developer on several projects (listed at the end) which will be 
> using OmniORB.  While NetBSD is not one our primary targets, it is the 
> machine I've decided to do most of my work in (because of the nice 
> cross platform development capabilities).

OK.

>    After looking at the build system (very nice BTW)

Very nice!?  Everyone else thinks it's a total nightmare.

>  , I thought it would be trivial to port OmniORB 
> over to NetBSD, and I'm willing to do the work and submit it back to 
> the project. Not only that, but I'm willing to write a very 
> comprehensive Porting HOWTO for future reference.

That would be good. I assume you have read the readme/PORTING file in
the distribution.

> I would only need a bit of help from one of the developers who can give 
> me information on the build system, and what would need touching up.  I 
> have experience with autoconf, automake, and such, but OmniORB uses 
> an...interesting...layout which I can't quite understand properly.  I 
> actually prefer using SCons, but I'm sure nobody want to move there (no 
> matter how sexy it is :-).

Actually, if you know how to drive SCons, I would be extremely
interested in support for building omniORB with it. As I say, the
current build process is a nightmare, and I really want to get rid of
it.

> 1.  Alright, so you've autoconf detecting the host and such in 
> configure.ac (which becomes configure).  Now, what version of autoconf 
> do you use?  How do you run it for your project (each one is different 
> it seems).  Is there a bootstrap.sh script that you use or do you do it 
> by hand?

It requires autoconf 2.52, as you can tell by looking at the AC_PREREQ
call at the top of configure.ac. You build the configure script with
aclocal; autoheader; autoconf.

> 2.  Once it is built, it seems that there are only a few places where 
> the __blah__ macros are used to configure the system.  Is it correct to 
> assume that the majority of these platform macros are in the omnithread 
> package?

Yes. To a large extent, they are a hold-over from the old build system
(which is still used by many platforms, including Windows). omnithread
still uses them, since it encapsulates knowledge about the pthreads
implementation that cannot be discovered by autoconf.

> 3.  NetBSD has had some troubles with pthreads in the past, but now 
> seems very much up to par with other OS.  Would it be worth it to try 
> and get pth to work as a drop in replacement for pthreads?  I think 
> this would really make OmniORB more portable in the future, and may 
> even give it a bit of a speed boost (I'm just guessing).

As far as I know, omnithread already works with pth. You just need to
make sure that when things link against libpthread, they get the pth
version. I've never tried it myself, though, so I might be wrong.

> 4.  Finally, is there a developer or contributor document that I can 
> use to learn your check-in procedures and such?

There is some info here:

  http://omniorb.sourceforge.net/cgi-bin/moin.cgi/SourceContributions

At the moment, the only person with check-in rights is me. Please send
patches and I'll integrate them if they're OK.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --