qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Huston" <shus...@riverace.com>
Subject RE: Cmake build update
Date Wed, 22 Apr 2009 20:09:51 GMT
Good points, Alan and Andrew...

I fixed up the rubygen script to be able to generate Makefile and
Cmake fragments, and have run a autoconf-style build on the cmake
branch successfully... Will now work on merging things back to trunk.

I'll let you know when it's available. Thanks for the suggestions and
support.

-Steve

> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com] 
> Sent: Wednesday, April 22, 2009 9:38 AM
> To: dev@qpid.apache.org
> Subject: Re: Cmake build update
> 
> 
> Steve Huston wrote:
> > Hi Andrew,
> > 
> >> On Tue, 2009-04-21 at 15:01 -0400, Steve Huston wrote:
> >>> Hi Qpideers,
> >>>
> >>> A while back I mentioned that Microsoft funded efforts to 
> >> improve the
> >>> qpid C++ build process, align the Linux/UNIX and Windows build
> >>> processes and end the problem where the Windows builds are a
step
> >>> behind the Linux builds when files change.
> >>>
> >>> As mentioned here previously, the initial approach to this is to
> > try
> >>> Cmake (www.cmake.org) and that has been going along well. The
> > basic
> >>> libraries (common, client, broker, cluster, ssl) and broker 
> >> build are
> >>> integrated. It's not yet ready for prime time, as the test build
> > and
> >>> execution isn't yet integrated. That'll probably be ready 
> >> for general
> >>> evaluation within a couple of weeks, but for the 
> >> adventurous among us
> >>> who want an early look, the work is happening on the 
> >> subversion cmake
> >>> branch (https://svn.apache.org/repos/asf/qpid/branches/cmake)
> >> Can this work sit alongside the existing build systems? If so I
> > don't
> >> think there's any reason not to do this work on the trunk.
> > 
> > It almost can at this point. The only real speed bump is one of
the
> > code generators - it was changed to generate cmake lists in 
> a way that
> > doesn't preserve the Makefile way. The other generator was 
> modified in
> > a compatible way. I'll look into making them both be able to do
both
> > .mk and .cmake output.
> > 
> > Other than that there were minor macro changes. As I recall, it's
> > primarily that CONF_FILE and MODULE_PATH. These are used in both
> > client and broker cases and specified with different values 
> depending
> > on the component being built. I changed this to QPIDD_CONF_FILE,
and
> > QPIDC_CONF_FILE (and similar for MODULE_PATH) and they're all set
in
> > the configuration step for cmake.
> > 
> >> It would certainly be an easier transition if the cmake
> > infrastructure
> >> doesn't happen at a stroke, dismantling the existing build
system,
> > but
> >> overlapping if possible for a short while (say a week or two).
> > 
> > I agree.
> 
> I think having both on trunk is essential for cmake adoption. 
> If we can have the 
> two co-exist while all concerned migrate their build systems 
> in their own time 
> then I think we will be able to get rid of libtool in fairly 
> short order. On the 
> other hand if try to propose a "big bang" where libtool 
> vanishes and cmake 
> appears, we'll probably never get everyone to agree on the 
> right time to do it.
> 
> I'm looking forward to seeing cmake on the trunk :)
> 
> 
>
---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> 
> 


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message