[omniORB] using cmake to build omniORB

[Michael]

I'd just reiterate, assuming omniorb is maintained via git-based repo with pull capability, then submit the PR.

On April 20, 2017 9:02:16 AM EDT, Titus von Boxberg via omniORB-list <omniorb-list at omniorb-support.com> wrote:
>> -----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
>
>_______________________________________________
>omniORB-list mailing list
>omniORB-list at omniorb-support.com
>http://www.omniorb-support.com/mailman/listinfo/omniorb-list

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20170420/860b3a7d/attachment.html>