CMake 3.14.0 available for download

I am happy to announce that CMake 3.14.0 is now available for download at:
https://cmake.org/download/

The first two 3.14.0 release candidates included the FindOcatave
module. This has been removed in rc3, and rc4 pending further development.

Documentation is available at:
https://cmake.org/cmake/help/v3.14

Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.14/release/3.14.html

Some of the more significant changes in CMake 3.14 are:

  • Support for running CMake on Windows XP and Windows Vista has been
    dropped. The precompiled Windows binaries provided on “cmake.org”
    now require Windows 7 or higher.
  • CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
    simple toolchain files.
  • The “Visual Studio 16 2019” generator was added. This is
    experimental and based on “Visual Studio 2019 Preview 4” because
    this version of VS has not been released.The VS 2019 generator differs from generators for earlier versions
    in that it does not provide variants that specify the target
    platform in the generator name. Instead “CMAKE_GENERATOR_PLATFORM”
    must be used, e.g. through the “-A” command-line option.
    Furthermore, the default target platform (architecture) is now based
    on the *host* platform. The VS host toolset selection is now based
    on the host architecture as well.
  • The “Green Hills MULTI” generator has been updated to include Object
    Library support, support for target renaming and destination output
    control properties, and other improvements.
  • A “CMAKE_BUILD_RPATH_USE_ORIGIN” variable and corresponding
    “BUILD_RPATH_USE_ORIGIN” target property were added to enable use of
    relative runtime paths (RPATHs). This helps achieving relocatable
    and reproducible builds that are invariant of the build directory.
  • The “install(TARGETS)” command learned how to install to an
    appropriate default directory for a given target type, based on
    variables from the “GNUInstallDirs” module and built-in defaults, in
    lieu of a “DESTINATION” argument.
  • The “install(FILES)” and “install(DIRECTORY)” commands learned a
    new set of parameters for installing files as a file type, setting
    the destination based on the appropriate variables from
    “GNUInstallDirs” and built-in defaults, in lieu of a “DESTINATION”
    argument.
  • The “install(CODE)” and “install(SCRIPT)” commands learned to
    support generator expressions. See policy “CMP0087”.
  • The “if()” command gained support for checking if cache variables
    are defined with the “DEFINED CACHE{VAR}” syntax.
  • A file-based api for clients to get semantic buildsystem
    information has been added. See the “cmake-file-api(7)” manual.
    This is intended to replace the “cmake-server(7)” mode for IDEs.
  • The “cmake(1)” Build Tool Mode (“cmake –build”) gained “–
    verbose” and “-v” options to specify verbose build output. Some
    generators such as Xcode don’t support this option currently.
  • The “cmake(1)” “-E compare_files” command learned a new “–ignore-
    eol” option to specify that end-of-line differences (e.g. LF vs
    CRLF) should be ignored when comparing files.
lt;Fortran_COMPILER_ID:…>” and “ lt;Fortran_COMPILER_VERSION:…>” generator expressions were added. * The “ lt;IN_LIST:…>” generator expression now correctly handles an empty argument. See “CMP0085” for details. Autogen ——- * The “AUTOMOC_EXECUTABLE”, “AUTORCC_EXECUTABLE”, and “AUTOUIC_EXECUTABLE” target properties were added. They all take a path to an executable and force automoc/autorcc/autouic to use this executable. Setting these will also prevent the configure time testing for these executables. This is mainly useful when you build these tools yourself. * The new variables “CMAKE_GLOBAL_AUTOGEN_TARGET”, “CMAKE_GLOBAL_AUTOGEN_TARGET_NAME”, “CMAKE_GLOBAL_AUTORCC_TARGET” and “CMAKE_GLOBAL_AUTORCC_TARGET_NAME” control the generation of global “autogen” and “autorcc” targets. * A new “CMAKE_AUTOGEN_ORIGIN_DEPENDS” variable and “AUTOGEN_ORIGIN_DEPENDS” target property may be set to enable or disable forwarding of the origin target dependencies to the corresponding “_autogen” target. CTest —– * “ctest(1)” gained a “–show-only=json-v1” option to show the list of tests in a machine-readable JSON format. See the Show as JSON Object Model section of the manual. * The “ctest_submit()” command learned a new “Done” part that can be used to inform CDash that a build is complete and that no more parts will be uploaded. * CTest learned to accept the dashboard server submission URL from a single variable. See the “SubmitURL” setting in “ctest(1)”, the “CTEST_SUBMIT_URL” variable, and the “SUBMIT_URL” argument of the “ctest_submit()” command. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies “CMP0064” and “CMP0065” (“CMP0063” and below were already deprecated). The “cmake-policies(7)” manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The “Xcode” generator deprecated support for Xcode versions prior to Xcode 5. Support for those will be dropped in a future version of CMake. * The “FindQt” module is no longer used by the “find_package()” command as a find module. This allows the Qt Project upstream to optionally provide its own “QtConfig.cmake” package configuration file and have applications use it via “find_package(Qt)” rather than “find_package(Qt CONFIG)”. See policy “CMP0084”. * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on “cmake.org” now require Windows 7 or higher. * CTest no longer supports submissions via “ftp”, “scp”, “cp”, and “xmlrpc”. CDash is the only maintained testing dashboard for CTest, and it only supports submissions over “http” and “https”. Other Changes ============= * Object library linking has been fixed to propagate private link libraries of object libraries to consuming targets. * Install rules under “add_subdirectory()” now interleave with those in the calling directory. See policy “CMP0082” for details. * CMake now imposes a maximum recursion limit to prevent a stack overflow on scripts that recurse infinitely. The limit can be adjusted at runtime with “CMAKE_MAXIMUM_RECURSION_DEPTH”. * When using cppcheck via the “CMAKE__CPPCHECK” variable or “_CPPCHECK” property, the build will now fail if “cppcheck” returns non-zero as configured by its command-line options. * Required link options to manage Position Independent Executable are now added when “POSITION_INDEPENDENT_CODE” is set. The project is responsible for using the “CheckPIESupported” module to check for “PIE” support to ensure that the “POSITION_INDEPENDENT_CODE” target property will be honored at link time for executables. This behavior is controlled by policy “CMP0083”. * Visual Studio Generators for VS 2010 and above learned to support the “VS_DEBUGGER_*” properties on targets created via “add_custom_target()”. * The “CPack” module no longer defaults to the “paxr” value in the “CPACK_DEBIAN_ARCHIVE_TYPE” variable, because “dpkg” has never supported the PAX tar format. The “paxr” value will be mapped to “gnutar” and a deprecation message emitted. * CMake no longer issues a warning if a target listed in an “install(TARGETS)” command has its “EXCLUDE_FROM_ALL” property set to true. —————————————————————————- Changes made since CMake 3.14.0-rc4: Brad King (2): VS: Revert “Use MSBuild matching toolset host architecture” CMake 3.14.0 Nils Gladitz (1): CMake: Fix WiX installer downgrades with versioned binaries

4 Responses to CMake 3.14.0 available for download

  1. The win64-x64 (from the msi installer) cmake.exe is getting detected by windows antivirus as Trojan:Win32/Skeeyah.I

  2. V says:

    Although virustotal no longer detects these files, I can see the two win64-x64 files having been modified 22th March without a notice and out of revision number, so may I ask whether they were compromised in any way?

    • Robert Maynard says:

      The original binaries had false positive reports, we regenerated the binaries with small tweaks that stopped the false positive reports. When we re-uploaded the win64-x64 binaries with these tweaks we also updated cmake-3.14.0-SHA-256.txt with the new sha256 signatures. Locally I have verified that the binaries have the same hash as what is in the SHA-256.txt

      • V says:

        Thanks for the quick reply. I was actually worried about the original ones (as I coincidentally came back to check their signatures) but now happy with this clarification.

Questions or comments are always welcome!

X