On 7/25/07, Alan W. Irwin <[EMAIL PROTECTED]> 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. That's a bad dance. It also slaves the release cycles of unrelated modules to each other. I'm not using most of the modules, and I really don't care if 1 pesky module wants VERSION 1.1.0 when I only need VERSION 1.0.0. The module release volunteers shouldn't be slaved to each other either. If they have to wait on what each and every module maintainer does, then they're not going to ship much of anything. Conversely, if they don't wait, then bumping the module version number doesn't mean anything for most of the modules. Having 1 CMake version number that everyone cares about, and a module version number for each and every module, might be reasonable. But those module version numbers would have to be documented to be of any use. CMake has big problems with transmission of documentation changes, just as bad as the module QA problems and just as much in need of more infrastructure. The module version number also has to assure something, like that bugs got fixed, new bugs didn't get introduced, interfaces are obeying modern coding standards, and/or new capabilities got added. Or else, why bother to check it? And of all these concerns, what are we actually interested in? Are volunteers going to document exactly how fixed or broken any of this is? Fat chance! Maybe others have great insights to offer here. But I strongly suspect that CMake QA simply is what it is, and all we can do is endeavor to improve it. The guarantee we're looking for is probably to require a given CMake version, monolithically. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
