I'm still using cmake 2.4 at home so I can confirm that everything
currently still works with a pretty complete build. I've not yet
upgraded to the latest version of ubuntu which does contain cmake 2.6.
This is principally because the kde support in the latest version is a
little cutting edge. Having said that I will probably get round to it at
some time, so don't hold things up for me. Is maintaining compatibility
(for now) really such a big deal? Many big users don't upgrade that often.
On Mon, Dec 22, 2008 at 07:36:48PM -0800, Alan Irwin wrote:
> I would like to bump the minimum version of CMake from the current 2.4.5 to
> 2.6.0. One motivation for moving to 2.6.x is our build system will be
> simplified by this move which will make it easier to do future changes to
> that build system. Another motivation is Fortran support is much better for
> 2.6.x. For example, we will be able to remove an annoying workaround in our
> Fortran source code that might confuse users who were "not in the know".
> (All occurrences of " use " in our Fortran source code comments have been
> replaced by "_use_" to avoid a bug in the 2.4.x fortran dependency parser.)
> A final motivation is I don't know of any developer who is actually still
> testing our build system for cmake-2.4.x. Because of that it is quite
> possible 2.4.x incompatibilities are creeping in, but instead of testing for
> those I would just prefer to keep our testing life as simple as possible and
> bump the minimum CMake version number instead.
> I have wanted to bump the CMake minimum version long before this but delayed
> it because at the time it would have caused trouble for packagers on
> platforms without access to CMake-2.6.0. However, my feeling is this is no
> longer an issue; Debian testing has long since moved to cmake-2.6.0, and I
> presume that is also the case for other distros.
> I plan to make the move soon (say two days from now to be definite) if I
> don't hear any strong objections.
> Alan W. Irwin
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> Linux-powered Science
> Plplot-devel mailing list