Thanks for the link. The backwards compatibility is something worth mentioning in the release notes, so that people can use it right away.
Am 1. Juli 2018 00:12:19 MESZ schrieb Craig Scott <craig.sc...@crascit.com>: >(Subject changed to be specific to this discussion) > >On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler ><p...@hendrik-sattler.de> >wrote: > >> It would actually make even more sense to rename >cmake_minimum_required() >> to cmake_version_required() with the new syntax or something similar. >Users >> of the old function cannot use the new syntax in older cmake versions >and >> the old name does not actually fit the new functionality. >> > >Actually older versions can use the new syntax and this is indeed the >specific reason why the new syntax is the way it is. Older CMake >versions >will see the extra dots as being version component separators and will >end >up effectively ignoring the max part. The nett result is that older >versions will continue to treat the min version as the policy setting >just >like they have been to date. Newer versions of CMake will be able to >take >advantage of the extra information provided by the max part to allow >newer >policies to be enforced. > >Regarding the renaming, a very similar discussion took place in the >merge >request itself, so I'll refer you to there for details: > >https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157 > > > > >> >> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" < >> ir...@beluga.phys.uvic.ca>: >> >On 2018-06-29 14:46-0400 Robert Maynard wrote: >> >[...] >> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)" >> >> commands now accept a version range using the form >> >> "<min>[...<max>]". The "<min>" version is required but policies >are >> >> set based on the "<max>" version. This allows projects to >specify a >> >> range of versions for which they have been updated and avoid >> >> explicit policy settings. >> >[...] >> > >> >I suggest the following change to the above description: >> > >> >but policies are set based on the "<max>" version. >> > >> >==> >> > >> >but policies are set based on the minimum of the running CMake and >> >"<max>" versions. >> > >> >I prefer the latter because it immediately answers the question >implied >> >by the former, i.e., >> >what happens if the running version is less than max? >> > >Seems reasonable. I've created a MR with a slight tweak to your wording >for >this here <https://gitlab.kitware.com/cmake/cmake/merge_requests/2180>. > >-- >Craig Scott >Melbourne, Australia >https://crascit.com
-- 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: https://cmake.org/mailman/listinfo/cmake
