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:acon...@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-subscr...@qpid.apache.org > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
