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:[email protected]
