[CMake] Call for Module maintainer volunteers

[Alan W. Irwin]

On 2007-07-25 11:58-0400 Mike Jackson wrote:

> I agree that some sort of consistency among all the modules is needed. 
> Consistent APIs help keep developer productivity high and the amount of 
> "surprises" to a minimum. When and how to aline the modules to a consistent 
> state is another whole debate. My thought is sooner rather than later

Absolutely.

> or do 
> it at a major CMake release number, like 3.0, or have the new modules that 
> break current CMakeLists.txt files as an Optional install for cmake, that way 
> those of us working on projects can use the newer versions.

My own hope is that we build a large module support community that makes
releases that are independent of the release schedule for the CMake core.
Those that wanted to be conservative about their module choices would follow
(by default) the minimum version of module release configured into the CMake
core (see below), but any given software package such as PLplot could demand
their users use a later module release than that minimum version thus
insuring widespread testing of cutting-edge module releases that would
eventually make them suitable candidates for the minimum version of module
release demanded by the CMake core.

Besides the obvious testing benefits of such an independent release schedule
for the CMake modules, I should also reveal a personal motivation. Right now
PLplot has an ever-increasing collection of new versions of modules that it
depends on since the new versions have bug fixes or features that are needed
by PLplot. These new versions are usually taken from cvs or from CMake bug
reports and put under our own svn control. Once those modules become part of
an official module release with its own version number, then I would be able
to drop these now redundant modules from PLplot distribution and simply
request our users to download a particular module release.  That makes life
simpler for me since I no longer have to check periodically with the CMake
CVS (or bug report) version to see if there have been any significant
updates.  So that is my personal motivation for wanting an independent
releases of CMake modules, but I suspect a number of other developers are in
exactly the same situation.

Independent module releases should not be that technically difficult to set
up since we are dealing only with simple ascii files with no builds required
for those who download the module release. It would be necessary to
configure each core CMake release to specify a minimum module release number
it will support.  Let's say we organize this in time for core CMake 2.4.8
which is configured with a minimum module release number of 1.0.0, an
official release of the modules consisting of the current set of modules
taken from cmake 2.4.7.  Then some added CMAKE_MODULE_MINIMUM_REQUIRED
functionality should also be added to the 2.4.8 core so that, e.g., PLplot
could say

CMAKE_MODULE_MINIMUM_REQUIRED(VERSION 1.1.0 FATAL_ERROR)

to demand all PLplot users use that later release of the modules or higher
to insure they use the module release that PLplot requires and which has
been thoroughly tested by the PLplot developers for our particular PLplot
needs.  Later on as more and more software packages adopt 1.1.0 as the
minimum module version, then that means the 1.1.0 versions of the modules
have become thoroughly tested under a wide variety of circumstances, and
under those conditions the cmake core developers will feel comfortable
bumping the minimum acceptable module version to 1.1.0.

My (Canadian) $0.02 worth about where I hope this is headed.

Alan
__________________________
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
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________