On 2015-04-28 14:54-0700 Alan W. Irwin wrote:
Also, a spurious warning is probably not that big a deal, but if you think the incorrect order of project(...) before cmake_minimum_required(...) could lead to more serious issues now or in the future as Platform code gets more and more complex, then I suggest you implement some code for one of those commands that enforces that order, subject, of course, to a policy so that you do not introduce backwards incompatibilities with this change.
Having thought about this some more, I am pretty sure what is going on is if any language support file refers to CMAKE_MINIMUM_REQUIRED_VERSION, then cmake_minimum_required must be called to define that variable before enabling languages (e.g., via project statements). The rest of this post assumes the above explanation is the correct one. To follow up, I looked at the files (some of which have to do with language support) in the Modules tree for the master branch tip version of CMake using the command software@raven> find . -type f |xargs grep -l CMAKE_MINIMUM_REQUIRED_VERSION ./GenerateExportHeader.cmake ./Platform/CYGWIN.cmake ./CMakeExportBuildSettings.cmake ./FindPkgConfig.cmake ./CMakeDetermineVSServicePack.cmake ./WriteCompilerDetectionHeader.cmake ./Qt4Macros.cmake If the only file in this list that affects language support is Platform/CYGWIN.cmake, there was some alternative to using CMAKE_MINIMUM_REQUIRED_VERSION in that logic, the C++ source code implementing language support does not refer to CMAKE_MINIMUM_REQUIRED_VERSION, and you can guarantee those conditions for all future language support then that would permanently solve the ordering issue as well. But, my feeling is the better practical solution is some code (not used unless the relevant Policy is NEW) to assure that cmake_minimum_required is always called (so that CMAKE_MINIMUM_REQUIRED_VERSION is defined) before any language is enabled. 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 __________________________ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
