On 2016-02-06 23:09-0800 Greg Jung wrote: > I'd like to make a pitch for maintaining a lower general cmake minimum > until > more compelling bug fixes or features are introduced. > I have over 6 platforms standardized on cmake 3.3.2. > Maybe the new version requirement should be restricted to those platforms > where they are needed? And an update message issued for those that are > not required to update? (i.e. "cmake 3.6.2 looks really spiffy; try it and > avoid > seeing this annoying message!")
Hi Greg: It is a difficult value judgement to decide how close to the CMake cutting edge we should be for our minimum version. From my build-system developer perspective it is good to stay close to the cutting edge since that minimizes the restrictions we have on taking advantage of bug fixes and new features that are constantly being developed for CMake. Also, self-diagnosis is much better for later CMake versions so tests of our build system on all platforms using cutting-edge CMake helps to reduce problematic CMake logic in our build system. But it is definitely convenient for our Linux users and other platforms like Cygwin that offer cmake as part of a coherent distribution of free software that we support a much older version of CMake as well. So that is why we support CMake 3.0.2 for Linux and Cygwin, but I am not really happy with that compromise since it forces us to work around some bugs/misfeatures in 3.0.2 that have long since been fixed in 3.3.2. For that reason I am definitely looking forward to bumping our Linux minimum to 3.3.2 just as soon as most Linux distributions offer that version or higher. And similar arguments can be made for Cygwin and possibly MinGW-w64/MSYS2. On the other hand, for those users who are using platforms such as MSVC _without_ a coherent free software distribution, my thought is they are going to have to build (or download from Kitware) a CMake version in any case so why not ask such users to use the latest matured version? This, of course, assumes our build system has been changed so that it works well with the latest matured version (although in the present case of the bump from the matured 3.3 to matured 3.4, i.e., from 3.3.2 to 3.4.3, no such build system changes were necessary). Note, that a new minor version of CMake, e.g., the 0, 1, 2, etc., in 3.0, 3.1, 3.2 etc. is released every 3 months or so that is the rough interval between when matured versions are released, e.g., between 3.3.2 and 3.4.3. So we assume that 3-month interval below. Anyhow, I don't think we are asking too much of our MSVC users (and users of other platforms without a coherent free software distribution) to download or build CMake every 3 months or so as 3.3.z, 3.4.z, etc., mature. Note, I am not asking you to do that for your Linux and Cygwin platforms, and I could add MinGW-w64/MSYS2 to the list of platforms where 3.0.2 is the minimum version as well if you think that is desireable. So my question for you is do you really think it is going to be that onerous for you to move from 3.3.2 to 3.4.3 just for MSVC and classical MinGW/MSYS? After all, I have already given 3.4.3 a pretty good thrashing on Linux so I expect there is an excellent chance it will be reliable for all your various platform needs as well. Finally, note that if you convince me to go with the second latest mature version (i.e., 3.3.2 now rather than 3.4.3) it will give you a 3-month break, but then after that, keeping up with second latest mature version will still require you to build/download CMake every 3 months or so. So why not go with latest mature rather than second latest if they are essentially going to be the same trouble for you? 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
