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 Tue, 21 Apr 2009 21:40:50 GMT
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
> > Cmake (www.cmake.org) and that has been going along well. The
> > libraries (common, client, broker, cluster, ssl) and broker 
> build are
> > integrated. It's not yet ready for prime time, as the test build
> > 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
> 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
> doesn't happen at a stroke, dismantling the existing build system,
> overlapping if possible for a short while (say a week or two).

I agree.

> It this isn't possible now (say due to some necessary changes in the
> source) then is it possible with a restricted amount of work to the
> existing build systems to make it so?

Yes, I am fairly sure this can go in parallel. When the work started,
it was not yet known how disruptive the switch would need to be so it
was kept off to the side. Now that we know more, I can most likely
merge it over.

> Thanks for this work

My pleasure... Thanks to Microsoft for funding it.

> I'll be very glad to get shot of libtool - the
> small amount of kde compiling I've done makes me like the cmake
> approach.

Yes, me too - so far I'm liking the cmake approach. It may take a bit
of work to get the downstream packaging processes adjusted, but many
people have already done so, and I'm sure we'll all be better off in
the end.


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

View raw message