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 __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake