Hi Roman,

I was not around for the original porting effort to CMake. The basics of 
converting
the QPID sources into common, broker, and client libraries under Visual Studio
worked very well from the start.

My part of the effort was to create a binding library that connects the above
mentioned libraries to clients running under .NET. For this effort neither CMake
nor autotools are any help. My main library is an 'interop dll'. It is compiled
with /CLR; it is C++ code that creates a .NET Assembly. 

With some effort the C++ project could probably be generated with CMake. But 
that
project could not be tightly integrated with the CSharp and Visual Basic 
examples.
As a result I have hand-generated solution and project files checked into the
code base.

Porting QPID to Visual Studio 2010 required little effort to port the CMake
generated parts and much effort for the rest.

-Chuck

----- Original Message -----
> From: "Steve Huston" <[email protected]>
> To: [email protected], [email protected]
> Sent: Thursday, December 15, 2011 11:07:27 AM
> Subject: RE: Apache QPID: autotools -> cmake
> 
> Hi Roman,
> 
> > I'm a graduate student at Queen's University writing a course
> > project on
> build
> > system refactoring. I read Steve Huston's article on his blog that
> > was
> > published in 2009 discussing why you chose cmake and how the
> > transition
> > was done and I was wondering if you have any additional information
> > I
> could
> > use for my research. Namely, can you elaborate on:
> 
> Sure.
> 
> Just to be clear, the Qpid C++ code base uses the cmake build; the
> Java
> side doesn't.
> 
> > - the most important reasons for adopting CMake over Autotools?
> 
> It could generate build inputs for both Microsoft Visual Studio and
> standard make. Other prominent projects seemed to have had success
> with
> it.
> 
> > What pros/cons of both systems mattered the most for QPID
> > developers?
> 
> The primary driver was the need to generate Visual Studio
> project/solution
> files as well as make files.
> 
> The cmake configuration could be edited (including with a modest GUI
> tool)
> and set up all the options in one place rather than having to use
> command
> line options for each option.
> 
> The autotools approach is well-known and understood (by users, at
> least).
> It can be something of a "black art" to use correctly as a developer,
> and
> cmake makes some improvement in that area.
> 
> > - did the fact that KDE successfully adapt cmake play a significant
> > role
> in you
> > picking it too?
> 
> Yes.
> 
> > - did you receive much help from cmake developers in designing your
> build
> > system?
> 
> Yes, sort of. We didn't need to design the build system from scratch,
> as
> the cmake build was patterned after the autotools build. However,
> Bill
> Hoffman at cmake was very helpful when problems and oddities came up.
> 
> > - how long did the transition take and how did it progress?
> 
> It's still in transition, as Alan mentioned. The primary push to get
> Windows and Linux both building with cmake took a couple of months if
> I
> remember correctly. Since both systems have been used in parallel
> since,
> there was occasional issues of one being updated but not the other.
> There
> are plans to finish the transition to cmake in the not too distant
> future.
> 
> > - were Apache QPID developers responsible for writing CMakeLists
> > and
> other
> > required files for their own packages (dispersed development) or is
> there a
> > build team that was in charge of producing those for all QPID
> > packages?
> 
> There were one or two people doing most of the initial transfer of
> autotools content to cmake. Once the basic build was in place it
> became
> every developer's job to maintain it when needed.
> 
> > Anything else you could mention would be of great help and much
> > appreciated!
> 
> I recommend that projects considering a change from one system to
> another
> plan on a very short parallel time, and quickly move to use of one
> system
> to ensure the new system gets completed and maintained as well as
> possible.
> 
> -Steve
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
> 
> 

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to