[CMake] Call for Module maintainer volunteers

[Alan W. Irwin]

On 2007-07-25 14:46-0400 Brandon Van Every wrote:

> On 7/25/07, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
>> 
>> CMAKE_MODULE_MINIMUM_REQUIRED(VERSION 1.1.0 FATAL_ERROR)
>
> Having 1 CMake version number that everyone cares about, and 1 CMake
> Module version number that everyone cares about, will simply confuse
> everybody as to what the heck they're requiring.

I covered off that issue by having a default minimum module release
configured for the cmake core.  Let's call that the "official" module
release.  Obviously that should be packaged with cmake itself (i.e., the
current situation). So the majority of software packagers who use CMake
won't even have to be worried about the possibility of alternative more
cutting-edge releases of modules.

> It also slaves the release cycles of unrelated modules to each other.
> [...]

True.  That is the whole point.  I believe the concerns you have expressed
are the standard concerns for the release of any software package made up of
different components, and I am not arguing that the module releases will be
any different in this regard.  However, I do argue it is better for the
modules to have an independent release cycle than the cmake core since that
allows more coherent testing (e.g., of release 1.1.0) of the latest set of
modules whose maintainers feel they are ready for such testing.

Let's make this discussion more concrete by taking a specific example.  I
have put together Ada language support for CMake. The requisite language
support modules now work for three platforms, and it is obviously time for
much wider testing. Currently, though, the Ada language modules are hidden
away on the PLplot svn server.  It will definitely be a step in the right
direction to get these modules into CMake cvs since that improves the
chances they will receive some additional testing.  However, as potential
maintainer of those modules it would be a big step for me to recommend to
Bill the Ada modules go into an integrated release of CMake without
substantial widespread testing on a variety of platforms, and the cvs
version may never get such testing.  (Other potential module maintainers
have already expressed this concern today.)

So having thought a bit more about this, what I believe we need is
well-publicized, easy to use, on-going experimental releases of modules.
That allows me to require PLplot users to download version x of an
experimental module release that the PLplot developers have already tested
for our needs, and that is much more convenient for PLplot users than giving
them a shopping list of various versions of modules in cvs that they must
independently download.

Once a module maintainer was satisfied with the testing his module received
in the experimental module releases, then he could recommend to Bill that
his module become part of the official module release that accompanies CMake
core releases. Note this is a substantial improvement over my earlier
suggestion which would have made it tough for Bill to ever update the
official modules all at once to some experimental module release since there
are bound to be some problems for certain modules in any such experimental
release.

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
__________________________