[omniORB] Missing idl file in /usr/share/idl/omniORB?

[Duncan Grisby]

On Friday 14 February, Thomas Lockhart wrote:

> OK, I'm working on building and installing the rest of the IDL for 
> omniORBpy. I have something going at least sort-of. I have a few questions:
> 
> 1) mk/beforeauto.mk has rules which deal with stubs etc. It looks like 
> some of it is inherited or reused from omniORB itself (though I haven't 
> verified this). Should the files in mk/ stay in sync with the other 
> distro, and hence should I focus on modifying rules in python/ instead? 
> istm that some of the existing rules are probably not used as-written in 
> omniORBpy.

The current organisation is an artifact of the way the autoconf based
configuration is derived from the original build mechanism using
platform makefiles and so on. omniORBpy was originally intended to be
built from inside the omniORB tree (it still is on Windows), and
copying the make rules was the easiest way to allow it to be built
outside.

The make files started as being identical to the ones in the omniORB
tree, but they have diverged slightly.

> 2) There are lots of files and directories generated from the COS IDL. 
> Is there a stylistic preference for generating them in-place in python/, 
> or instead having a separate subdirectory holding the stub products? In 
> the latter case there could be local makefiles or it could just be a 
> container for the stubs. There is some mention in the makefiles of a 
> $(TOP)/stub/ directory, but it does not seem to be used by omniORBpy (or 
> by omniORB). Recommendations?

The $(TOP)/stub directory is used by the C++ example programs, and
anything else that gets integrated with the omniORB tree. References
to it in omniORBpy are just hold-overs from history.

The whole omniORB build system is a horrible mess. It is really three
different overlapping systems. The first is the Omni Development
Environment that was used internally at ORL / AT&T, which permitted
the use of a hierarchy of layered source trees, and very easy
configuration and building of all sorts of projects. On top of that is
the make system using config.mk and platform makefiles, which stripped
out some of the ODE facilities to avoid people having to set up a
relatively complex build system. On top of _that_ it the autoconf
stuff that modifies it to allow autoconf to sort a lot of things out,
and reintroduces the ODE's facility for building in a separate place
to the source tree.

For omniORB 4.0 I really wanted to throw it all away and replace it
with something cleaner, but none of the options available were
suitable without a huge amount of work.

> 3) Is there an interest in using python's DistUtils to generate these 
> packages rather than doing it explicitly using make?

Maybe, but last time I looked it didn't seem to be up to the job of
building complex C++ extensions.

I think the best hope for the whole omniORB build environment is
SCons.

Cheers,

Duncan.

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