Re: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
> Users of the old function cannot use the new syntax in older cmake versions The new cmake_minimum_required syntax of MIN...POLICY_MAX is entirely backwards compatible and will just be ignored by cmake < 3.12. On Sat, Jun 30, 2018 at 1:14 AM Hendrik Sattler 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. > > > Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" > : > >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 > >> "[...]". The "" version is required but policies are > >> set based on the "" 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 "" version. > > > >==> > > > >but policies are set based on the minimum of the running CMake and > >"" 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? > > > >Alan > >__ > >Alan W. Irwin > > > >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: > https://cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
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. Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" : >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 >> "[...]". The "" version is required but policies are >> set based on the "" 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 "" version. > >==> > >but policies are set based on the minimum of the running CMake and >"" 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? > >Alan >__ >Alan W. Irwin > >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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
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 "[...]". The "" version is required but policies are set based on the "" 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 "" version. ==> but policies are set based on the minimum of the running CMake and "" 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? Alan __ Alan W. Irwin 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: https://cmake.org/mailman/listinfo/cmake
[CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
I am proud to announce the second CMake 3.12 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.12
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.12/release/3.12.html
Some of the more significant changes in CMake 3.12 are:
* The "target_link_libraries()" command now supports Object
Libraries. Linking to an object library uses its object files in
direct dependents and also propagates usage requirements.
* The "target_link_libraries()" command may now be called to modify
targets created outside the current directory.
* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
flag "CONFIGURE_DEPENDS" which enables expression of build system
dependency on globbed directory's contents.
* The "Compile Features" functionality is now aware of C++ 20. No
specific features are yet enumerated besides the "cxx_std_20" meta-
feature.
* The Visual Studio Generators for VS 2017 learned to support a
"version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
via the "cmake(1)" "-T" option) to specify a toolset version number.
* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
parallel []" and "-j []" options to specify a parallel
build level. They map to corresponding options of the native build
tool.
* The "add_compile_definitions()" command was added to set
preprocessor definitions at directory level. This supersedes
"add_definitions()".
* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
commands now accept a version range using the form
"[...]". The "" version is required but policies are
set based on the "" version. This allows projects to specify a
range of versions for which they have been updated and avoid
explicit policy settings.
* The "find_package()" command now searches a prefix specified by a
"PackageName_ROOT" CMake or environment variable. Package roots are
maintained as a stack so nested calls to all "find_*" commands
inside find modules also search the roots as prefixes. See policy
"CMP0074".
* A new "$" and "$"
"generator expression" has been added to enable consumption of
generator expressions whose evaluation results itself in generator
expressions.
* A new "$" "generator expression" has been
added.
* A new "$" "generator expression" has
been added.
* The "FindCURL" module now provides imported targets.
* The "FindJPEG" module now provides imported targets.
* A "FindODBC" module was added to find an Open Database
Connectivity (ODBC) library.
* New "FindPython3" and "FindPython2" modules, as well as a new
"FindPython" module, have been added to provide a new way to locate
python environments.
CMake 3.12 Release Notes
Changes made since CMake 3.11 include the following.
New Features
Generators
--
* The Visual Studio Generators for VS 2017 learned to support a
"version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
via the "cmake(1)" "-T" option) to specify a toolset version number.
Command-Line
* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
parallel []" and "-j []" options to specify a parallel
build level. They map to corresponding options of the native build
tool.
Commands
* The "add_compile_definitions()" command was added to set
preprocessor definitions at directory level. This supersedes
"add_definitions()".
* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
commands now accept a version range using the form
"[...]". The "" version is required but policies are
set based on the "" version. This allows projects to specify a
range of versions for which they have been updated and avoid
explicit policy settings.
* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
flag "CONFIGURE_DEPENDS" which enables expression of build system
dependency on globbed directory's contents.
* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
to expose "TOUCH" functionality without having to use CMake's
command- line tool mode with "execute_process()".
* The "find_package()" command now searches a prefix specified by a
"PackageName_ROOT" CMake or environment variable. Package roots are
maintained as a stack so nested calls to all "find_*" commands
inside find modules also search the roots as prefixes. See policy
"CMP0074".
* The "install()" command learned an optional "NAMELINK_COMPONENT"
parameter, which allows you to change the component for a shared
library's namelink. If none is specified, the value of "COMPONENT"
is used by default.
* The "list()" command learned a "JOIN" sub-command to concatenate
list's elements separated by a glue string.
* The "list()" command learned a "SUBLIST" sub-command to get a
sublist of the list.
* The "list()" command learned a "TRANSFORM" sub-command to apply
