qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Cmake build update
Date Wed, 22 Apr 2009 13:37:33 GMT
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

View raw message