[prev in list] [next in list] [prev in thread] [next in thread]
List: omniorb-list
Subject: Re: [omniORB] using cmake to build omniORB
From: Michael via omniORB-list <omniorb-list () omniorb-support ! com>
Date: 2017-04-20 14:58:45
Message-ID: 8a8df633-52e5-4b37-a7e0-e5028e2b4af5 () email ! android ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@omniorb-support.com> wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: Duncan Grisby [mailto:duncan@grisby.org]
> > Gesendet: Donnerstag, 20. April 2017 12:37
> > An: Titus von Boxberg <titus@elbe-informatik.de>;
> omniorb-list@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@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.
[Attachment #5 (text/html)]
<html><head></head><body>I'd just reiterate, assuming omniorb is maintained via \
git-based repo with pull capability, then submit the PR.<br><br><div \
class="gmail_quote">On April 20, 2017 9:02:16 AM EDT, Titus von Boxberg via \
omniORB-list <omniorb-list@omniorb-support.com> wrote:<blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;"> <pre class="k9mail"><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: \
1ex;"> -----Ursprüngliche Nachricht-----<br /> Von: Duncan Grisby \
[mailto:duncan@grisby.org]<br /> Gesendet: Donnerstag, 20. April 2017 12:37<br /> An: \
Titus von Boxberg <titus@elbe-informatik.de>; omniorb-list@omniorb-<br /> <a \
href="http://support.com">support.com</a><br /> Betreff: Re: [omniORB] using cmake to \
build omniORB<br /> <br /> On Fri, 2017-04-14 at 09:32 +0000, Titus von Boxberg via \
omniORB-list<br /> wrote:<br /> <br /><blockquote class="gmail_quote" style="margin: \
0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Could there \
be a consensus to switch the build system to CMake?<br /> What other conditions would \
have to be met?<br /> What objections do you see against this switch?<br \
/></blockquote> <br /> omniORB's build system is definitely rather over complex, with \
some<br /> historical baggage associated with it. On the whole it works fine, \
though,<br /> so I don't see it as a huge priority to change it.<br /> <br /> If you \
can provide a CMake based build and demonstrate that it has clear<br /> advantages \
over the current scheme, and still supports all the strange old<br /> platforms \
supported in the current system, we could definitely switch to<br /> using it.<br \
/></blockquote><br />I have now made up a CMake configuration that works for Windows \
and Linux.<br />AFAICS it's compatible with the existing build system.<br \
/>Exception: Currently, the windows libraries do not follow the existing naming \
scheme<br />but the more standard cmake & boost scheme (implibs are libxxx.lib, \
dlls are xxx.(dll|lib)).<br /><br />Under Linux the cmake scripts fill a header based \
on <a href="http://acconfig.h.in">acconfig.h.in</a> with the HAVE_ values<br \
/>determined by the cmake scripts.<br />Under Windows I use the _trad stuff with \
OMNI_CONFIG_TRADITIONAL.<br /><br />Furthermore, the build system provides 1-step \
cross compilation (to Linux).<br /><br />I did not modify any omniORB sources except \
<a href="http://idlpython.cc">idlpython.cc</a> so that omniidl can<br />find the just \
installed python lib dir without -p when bin is not<br />in an "arch" directory like \
x86_win32.<br /><br />I have ported the other automatic generation steps like \
distdate.hh and<br />DLL export symbols extraction to cmake so there is no system or \
external script<br />interpreter dependency left (which I think is one of the really \
nifty advantages<br />of cmake). Still missing are the DLL manifests.<br /><br />I \
have not yet spent time on getting really well useable VS solutions<br />out of \
cmake. This is the next step for the coming days.<br />At least for my purposes, this \
is *the* advantage of the cmake build system.<br /><br />I don't have any interest in \
being backwards compatible to ancient operating systems.<br />I have access to \
FreeBSD and MacOS machines, so I could extend the scripts to handle<br />these \
systems.<br />If someone really is interested in strange old platforms, the cmake \
build system<br />could be easily extended.<br />I took care to error out in \
if-else-statements when the target OS is unknown.<br />For my applications it would \
rather be interesting to remove all the old clutter (e.g. omnithread)<br />and switch \
to C++14/7. But that has not directly to do with cmake.<br /><br />Let me know if \
you're still interested.<br /><br />Titus<br /><br /><hr /><br />omniORB-list mailing \
list<br />omniORB-list@omniorb-support.com<br /><a \
href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br \
/></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic