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. > 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. Thanks, -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
