[omniORB] using cmake to build omniORB

[Titus von Boxberg]

> -----Ursprüngliche Nachricht-----
> Von: Duncan Grisby [mailto:duncan at grisby.org]
> Gesendet: Donnerstag, 20. April 2017 12:37
> An: Titus von Boxberg <titus at elbe-informatik.de>; omniorb-list at omniorb-
> support.com
> Betreff: Re: [omniORB] using cmake to build omniORB
> 
> On Fri, 2017-04-14 at 09:32 +0000, Titus von Boxberg via omniORB-list
> wrote:
> 
> > Could there be a consensus to switch the build system to CMake?
> > What other conditions would have to be met?
> > What objections do you see against this switch?
> 
> omniORB's build system is definitely rather over complex, with some
> historical baggage associated with it. On the whole it works fine, though,
> so I don't see it as a huge priority to change it.
> 
> If you can provide a CMake based build and demonstrate that it has clear
> advantages over the current scheme, and still supports all the strange old
> platforms supported in the current system, we could definitely switch to
> using it.

I have now made up a CMake configuration that works for Windows and Linux.
AFAICS it's compatible with the existing build system.
Exception: Currently, the windows libraries do not follow the existing naming scheme
but the more standard cmake & boost scheme (implibs are libxxx.lib, dlls are xxx.(dll|lib)).

Under Linux the cmake scripts fill a header based on acconfig.h.in with the HAVE_ values
determined by the cmake scripts.
Under Windows I use the _trad stuff with OMNI_CONFIG_TRADITIONAL.

Furthermore, the build system provides 1-step cross compilation (to Linux).

I did not modify any omniORB sources except idlpython.cc so that omniidl can
find the just installed python lib dir without -p when bin is not
in an "arch" directory like x86_win32.

I have ported the other automatic generation steps like distdate.hh and
DLL export symbols extraction to cmake so there is no system or external script
interpreter dependency left (which I think is one of the really nifty advantages
of cmake). Still missing are the DLL manifests.

I have not yet spent time on getting really well useable VS solutions
out of cmake. This is the next step for the coming days.
At least for my purposes, this is *the* advantage of the cmake build system.

I don't have any interest in being backwards compatible to ancient operating systems.
I have access to FreeBSD and MacOS machines, so I could extend the scripts to handle
these systems.
If someone really is interested in strange old platforms, the cmake build system
could be easily extended.
I took care to error out in if-else-statements when the target OS is unknown.
For my applications it would rather be interesting to remove all the old clutter (e.g. omnithread)
and switch to C++14/7. But that has not directly to do with cmake.

Let me know if you're still interested.

Titus