CMake "State of the Union"

[Steve Huston <sh...@riverace.com>]

My fellow Qpideers, the state of the CMake union is, uh, well, sort of
ok...

A couple of weeks ago I raised the point that enthusiastic commitments
to the Cmake transition for the C++ builds early on have dwindled
considerably. The Cmake build seems a bit orphaned in Linux land. At
the start of the Cmake effort, Andrew Stitcher stepped up and make a
bunch of nice improvements to the Cmake files. As time went on, things
dwindled somewhat. For the recent past, changes to the Makefile.am
files get the corresponding Cmake changes inconsistently.

It was recently asked on the list what needs to be done to get Cmake
to be the preferred vehicle for builds. Here's what I believe is
needed:

- The python preprocessing scheme needs to be transferred to Cmake
(this is an example of a significant change made to autoconf, but not
made to Cmake). Without this, the Cmake test scripts are looking for
the python test in the wrong place. (This issue is in QPID-2127)

- Someone with experience in Qpid releasing needs to look at what
happens during a release and help work out anything needed to get a
good release out based on the Cmake system. Also, any doc changes
needed for users.

- Get someone to try generating an RPM from the Cmake build and see
how that compares to the RPMs built via autoconf. Adjust and improve
as needed.

- Supply more builds to the Cdash dashboard at
http://www.riverace.com/CDash-1.4.2/index.php?project=qpid-cpp - I
have a RHEL 5 and a Windows XP build there now. The dashboard is
driven by outputs from the Cmake build - it makes it very easy to
watch the trends, note where tests are failing, make some estimation
of what changes caused the problems and who made them, etc. Getting
all the build and regression info in one place goes a long way toward
helping the entire development crew keep an eye on things. If having
this hosted at riverace.com is a problem, I'm available to help
migrate it to qpid.apache.org.

- Set a deadline for transition to Cmake and deletion of the autoconf
files. I understand the fact that for Linux developers, the path of
least resistance is to stick with what's known. Therefore, some hard
goal is probably what will be needed to make the transition.

The goal at the start of the Cmake effort was to get one common build
system for all Qpid C++ platforms. That goal was pretty
enthusiastically assented to. We're close to a unified system, but in
order to keep this from degenerating closer to a two-scheme build
system with Visual Studio projects replaced by Cmake files, we need to
make a push to get the rest of the way to a single system.

Can we get some volunteers to pick up the items above and help
complete this effort?

Thanks,
-Steve


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

Re: CMake "State of the Union"

[Carl Trieloff <cc...@redhat.com>]

>
> - Supply more builds to the Cdash dashboard at
> http://www.riverace.com/CDash-1.4.2/index.php?project=qpid-cpp - I
> have a RHEL 5 and a Windows XP build there now. The dashboard is
> driven by outputs from the Cmake build - it makes it very easy to
> watch the trends, note where tests are failing, make some estimation
> of what changes caused the problems and who made them, etc. Getting
> all the build and regression info in one place goes a long way toward
> helping the entire development crew keep an eye on things. If having
> this hosted at riverace.com is a problem, I'm available to help
> migrate it to qpid.apache.org.
>   

I don't have an issue it being at riverace.com, however if you want to 
ask on #asfinfra they
might be fine with us running it qpid.apache.org.  They will however 
require it be all OS
licensed or something like that. if it is not, we use ptol, which is 
built using qpid which could
also be setup at apache if there is interest.

The advantage of having it run at apache.org is that more people can 
setup and maintain
test profiles, currently I see 4 profiles red on our trunk build system.

> - Set a deadline for transition to Cmake and deletion of the autoconf
> files. I understand the fact that for Linux developers, the path of
> least resistance is to stick with what's known. Therefore, some hard
> goal is probably what will be needed to make the transition.

 From what I can see CMake is coming along well. I don't think autotools 
can be removed at
the 0-6 release, as we should give enough time for the upstream and 
downstream projects to
update themselves. We probably need to get two or three releases out 
with CMake, so I would
think knowing all is good and ready to remove autotool would most likely 
be sometime
around spring.


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