[ANNOUNCE] CMake 3.6.0-rc4 now ready for testing!

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] CMake 3.6.0-rc4 now ready for testing!

Robert Maynard
I am proud to announce the fourth CMake 3.6 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

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

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

Some of the more significant features of CMake 3.6 are:

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.

* A "<LANG>_CLANG_TIDY" target property and supporting
  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.

Deprecated and Removed Features
===============================

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "Visual Studio 7 .NET 2003" generator is now deprecated and
  will be removed in a future version of CMake.

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.



CMake 3.6 Release Notes
***********************

Changes made since CMake 3.5 include the following.


New Features
============


Generators
----------

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/all" to drive the build of a subdirectory. This is
  equivalent to "cd sub/dir; make all" with Makefile Generators.

* The "Ninja" generator now includes system header files in build
  dependencies to ensure correct re-builds when system packages are
  updated.

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
  property.

* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
  leave installation rules out of the default installation.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%s" placeholder.  This is the number of seconds
  since the UNIX Epoch.


Variables
---------

* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
  Makefile Generators to limit dependency scanning only to files in
  the project source and build trees.

* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
  when CMake is running on an Oracle Solaris host.

* A "CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES" variable was added
  for use by toolchain files to specify system include directories to
  be appended to all compiler command lines.

* The "CMAKE_<LANG>_STANDARD_LIBRARIES" variable is now documented.
  It is intended for use by toolchain files to specify system
  libraries to be added to all linker command lines.

* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
  the "Ninja" generator to configure the generated "build.ninja" file
  for use as a "subninja".

* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
  use by toolchain files to specify platform-specific variables that
  must be propagated by the "try_compile()" command into test
  projects.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.


Properties
----------

* A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to
  tell the "Visual Studio 9 2008" and "Visual Studio 8 2005"
  generators to generate the "remote directory" for WinCE project
  deployment and debugger settings.

* A "<LANG>_CLANG_TIDY" target property and supporting
  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally
  tell CTest to enforce a secondary timeout after matching certain
  output from a test.

* A "VS_CONFIGURATION_TYPE" target property was introduced to
  specify a custom project file type for Visual Studio Generators
  supporting VS 2010 and above.

* A "VS_STARTUP_PROJECT" directory property was introduced to
  specify for Visual Studio Generators the default startup project for
  generated solutions (".sln" files).


Modules
-------

* The "CMakePushCheckState" module now pushes/pops/resets the
  variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize".

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1"
  argument to skip extracting the file that is downloaded (e.g., for
  self-extracting shell installers or ".msi" files).

* The "ExternalProject" module now uses "TLS_VERIFY" when fetching
  from git repositories.

* The "FindBLAS" and "FindLAPACK" modules learned to support
  OpenBLAS.

* The "FindCUDA" module learned to find the "cublas_device" library.

* The "FindGTest" module "gtest_add_tests" function now causes CMake
  to automatically re-run when test sources change so that they can be
  re-scanned.

* The "FindLTTngUST" module was introduced to find the LTTng-UST
  library.

* The "FindPkgConfig" module learned to optionally create imported
  targets for the libraries it has found.

* The "FindProtobuf" module learned to provide a "Protobuf_VERSION"
  variable and check the version number requested in a
  "find_package()" call.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.


Platforms
---------

* The Clang compiler is now supported on CYGWIN.

* Support was added for the Bruce C Compiler with compiler id
  "Bruce".


CTest
-----

* The "ctest_update()" command now looks at the
  "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules
  should be updated or not before updating.

* The "ctest_update()" command will now synchronize submodules on an
  update. Updates which add submodules or change a submodule's URL
  will now be pulled properly.


CPack
-----

* The "CPackDeb" module learned how to handle "$ORIGIN" in
  "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used
  for dependency auto detection.

* The "CPackDeb" module learned how to generate "DEBIAN/shlibs"
  contorl file when package contains shared libraries.

* The "CPackDeb" module learned how to generate "DEBIAN/postinst"
  and "DEBIAN/postrm" files if the package installs libraries in
  ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/").

* The "CPackDeb" module learned how to generate dependencies between
  Debian packages if multi-component setup is used and
  "CPACK_COMPONENT_<compName>_DEPENDS" variables are set. For backward
  compatibility this feature is disabled by default. See
  "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS".

* The "CPackDeb" module learned how to set custom package file names
  including how to generate properly-named Debian packages:

     <PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

  For backward compatibility this feature is disabled by default. See
  "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN_<COMPONENT>_FILE_NAME".

* The "CPackDeb" module learned how to set the package release
  number ("DebianRevisionNumber" in package file name when used in
  combination with "DEB-DEFAULT" value set by
  "CPACK_DEBIAN_FILE_NAME").  See "CPACK_DEBIAN_PACKAGE_RELEASE".

* The "CPackDeb" module learned how to set the package architecture
  per-component.  See "CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE".

* The "CPackDMG" module learned a new option to tell the CPack
  "DragNDrop" generaor to skip the "/Applications" symlink. See the
  "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable.

* The "CPackIFW" module gained a new "cpack_ifw_update_repository()"
  command to update a QtIFW-specific repository from a remote
  repository.

* The "CPackRPM" module learned how to set RPM "dist" tag as part of
  RPM "Release:" tag when enabled (mandatory on some Linux
  distributions for e.g. on Fedora). See
  "CPACK_RPM_PACKAGE_RELEASE_DIST".

* The "CPackRPM" module learned how to set default values for owning
  user/group and file/directory permissions of package content. See
  "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP",
  "CPACK_RPM_DEFAULT_FILE_PERMISSIONS",
  "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component
  counterparts.

* The "CPackRPM" module learned how to set user defined package file
  names, how to specify that rpmbuild should decide on file name
  format as well as handling of multiple rpm packages generated by a
  single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and
  "CPACK_RPM_<component>_PACKAGE_NAME".

* The "CPackRPM" module learned how to correctly handle symlinks
  that are pointing outside generated packages.


Other
-----

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.


Deprecated and Removed Features
===============================

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "find_library()", "find_path()", and "find_file()" commands no
  longer search in installation prefixes derived from the "PATH"
  environment variable on non-Windows platforms.  This behavior was
  added in CMake 3.3 to support Windows hosts but has proven
  problematic on UNIX hosts. Users that keep some "<prefix>/bin"
  directories in the "PATH" just for their tools do not necessarily
  want any supporting "<prefix>/lib" directories searched.  One may
  set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of
  prefixes that are to be searched.

* The "Visual Studio 7 .NET 2003" generator is now deprecated and
  will be removed in a future version of CMake.

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.


Other Changes
=============

* The precompiled OS X binary provided on "cmake.org" now requires
  OS X 10.7 or newer.

* On Linux and FreeBSD platforms, when building CMake itself from
  source and not using a system-provided libcurl, OpenSSL is now used
  by default if it is found on the system.  This enables SSL/TLS
  support for commands supporting network communication via "https",
  such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()".

* The "cmake(1)" "--build" command-line tool now rejects multiple
  "-- target" options with an error instead of silently ignoring all
  but the last one.

* "AUTOMOC" now diagnoses name collisions when multiple source files
  in different directories use "#include <moc_foo.cpp>" with the same
  name (because the generated "moc_foo.cpp" files would collide).

* The "FindBISON" module "BISON_TARGET" macro now supports special
  characters by passing the "VERBATIM" option to internal
  "add_custom_command()" calls.  This may break clients that added
  escaping manually to work around the bug.

* The "FindFLEX" module "FLEX_TARGET" macro now supports special
  characters by passing the "VERBATIM" option to internal
  "add_custom_command()" calls.  This may break clients that added
  escaping manually to work around the bug.

* The "FindProtobuf" module input and output variables were all
  renamed from "PROTOBUF_" to "Protobuf_" for consistency with other
  find modules. Input variables of the old case will be honored if
  provided, and output variables of the old case are always provided.

* The "CPackRPM" module now supports upper cased component names in
  per component CPackRPM specific variables. E.g. component named
  "foo" now expects component specific variable to be
  "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected
  "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in
  variables is compatible with convention used for other CPack
  variables. For back compatibility old format of variables is still
  valid and preferred if both versions of variable are set, but the
  preferred future use is upper cased component names in variables.
  New variables that will be added to CPackRPM in later versions will
  only support upper cased component variable format.

----------------------------------------------------------------------------
Changes made since CMake 3.6.0-rc3:

Bartosz Kosiorek (1):
      Help: Describe VERSION and SOVERSION meanings for Mach-O binaries

Ben Boeckel (1):
      ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files

Brad King (2):
      Revert "try_compile: Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes"
      CMake 3.6.0-rc4

Gregor Jasny (1):
      Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)

Robert Maynard (5):
      FindHDF5: correctly add lang to each component target name.
      FindHDF5: Handle HDF5 builds with non-suffixed components
      FindHDF5: When component targets not found fallback to compiler wrappers
      FindHDF5: cache the correct path to the high level libraries
      FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake

Rolf Eike Beer (1):
      GetPrerequisites: fix typo in comment
--

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
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing!

Hendrik Sattler


Am 29. Juni 2016 21:30:40 MESZ, schrieb Robert Maynard <[hidden email]>:

>I am proud to announce the fourth CMake 3.6 release candidate.
>
>Sources and binaries are available at:
>  https://cmake.org/download/
>
>Documentation is available at:
>  https://cmake.org/cmake/help/v3.6
>
>Release notes appear below and are also published at
>  https://cmake.org/cmake/help/v3.6/release/3.6.html
>
>Some of the more significant features of CMake 3.6 are:
>
>* The "Visual Studio 14 2015" generator learned to support the
>  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
>  feature is experimental.
>
>* The "list()" command gained a "FILTER" sub-command to filter list
>  elements by regular expression.

This would also be very handy for generator expressions, similar to JOIN.

>* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
>  tell the "try_compile()" command to build a static library instead
>  of an executable.  This is useful for cross-compiling toolchains
>  that cannot link binaries without custom flags or scripts.
>
>* A "<LANG>_CLANG_TIDY" target property and supporting
>  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
>  Makefile Generators and the "Ninja" generator to run "clang-tidy"
>  along with the compiler for "C" and "CXX" languages.
>
>* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
>  perform a shallow clone of a Git repository.
>
>* The "ExternalProject" module learned to initialize Git submodules
>  recursively and also to initialize new submodules on updates.  Use
>  the "GIT_SUBMODULES" option to restrict which submodules are
>  initalized and updated.
>
>* The "InstallRequiredSystemLibraries" module learned a new
>  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
>  of the Windows Universal CRT libraries with Visual Studio 2015.
 
Maybe the help should note that this is only needed when targeting WindowsXP.

>* The "Compile Features" functionality is now aware of features
>  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
>  platforms.
>
>Deprecated and Removed Features
>===============================
>
>* The "CMakeForceCompiler" module and its macros are now deprecated.
>  See module documentation for an explanation.
>
>* The "Visual Studio 7 .NET 2003" generator is now deprecated and
>  will be removed in a future version of CMake.
>
>* The "Visual Studio 7" generator (for VS .NET 2002) has been
>  removed. It had been deprecated since CMake 3.3.
>
>* The "Visual Studio 6" generator has been removed. It had been
>  deprecated since CMake 3.3.
>
>
>
>CMake 3.6 Release Notes
>***********************
>
>Changes made since CMake 3.5 include the following.
>
>
>New Features
>============
>
>
>Generators
>----------
>
>* The "Ninja" generator learned to produce phony targets of the form
>  "sub/dir/all" to drive the build of a subdirectory. This is
>  equivalent to "cd sub/dir; make all" with Makefile Generators.
>
>* The "Ninja" generator now includes system header files in build
>  dependencies to ensure correct re-builds when system packages are
>  updated.
>
>* The "Visual Studio 14 2015" generator learned to support the
>  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
>  feature is experimental.
>
>
>Commands
>--------
>
>* The "add_custom_command()" and "add_custom_target()" commands
>  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
>  property.
>
>* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
>  leave installation rules out of the default installation.
>
>* The "list()" command gained a "FILTER" sub-command to filter list
>  elements by regular expression.
>
>* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
>  support for the "%s" placeholder.  This is the number of seconds
>  since the UNIX Epoch.
>
>
>Variables
>---------
>
>* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
>  Makefile Generators to limit dependency scanning only to files in
>  the project source and build trees.
>
>* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
>  when CMake is running on an Oracle Solaris host.
>
>* A "CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES" variable was added
>  for use by toolchain files to specify system include directories to
>  be appended to all compiler command lines.
>
>* The "CMAKE_<LANG>_STANDARD_LIBRARIES" variable is now documented.
>  It is intended for use by toolchain files to specify system
>  libraries to be added to all linker command lines.
>
>* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
>  the "Ninja" generator to configure the generated "build.ninja" file
>  for use as a "subninja".
>
>* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
>  use by toolchain files to specify platform-specific variables that
>  must be propagated by the "try_compile()" command into test
>  projects.

Can someone please add an example to the help. The use case for adding this variable is completely left in the dark.
E.g. I tried to make the initial try_compile() to respect my CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file... does nothing. So I really have to use CXXFLAGS environment variable which feels clumsy.
It's that really the only reliable way to define compiler arguments like -mcpu= for all compiler invocations?

>* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
>  tell the "try_compile()" command to build a static library instead
>  of an executable.  This is useful for cross-compiling toolchains
>  that cannot link binaries without custom flags or scripts.
>
>
>Properties
>----------
>
>* A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to
>  tell the "Visual Studio 9 2008" and "Visual Studio 8 2005"
>  generators to generate the "remote directory" for WinCE project
>  deployment and debugger settings.
>
>* A "<LANG>_CLANG_TIDY" target property and supporting
>  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
>  Makefile Generators and the "Ninja" generator to run "clang-tidy"
>  along with the compiler for "C" and "CXX" languages.
>
>* A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally
>  tell CTest to enforce a secondary timeout after matching certain
>  output from a test.
>
>* A "VS_CONFIGURATION_TYPE" target property was introduced to
>  specify a custom project file type for Visual Studio Generators
>  supporting VS 2010 and above.
>
>* A "VS_STARTUP_PROJECT" directory property was introduced to
>  specify for Visual Studio Generators the default startup project for
>  generated solutions (".sln" files).
>
>
>Modules
>-------
>
>* The "CMakePushCheckState" module now pushes/pops/resets the
>  variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize".
>
>* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
>  perform a shallow clone of a Git repository.
>
>* The "ExternalProject" module learned to initialize Git submodules
>  recursively and also to initialize new submodules on updates.  Use
>  the "GIT_SUBMODULES" option to restrict which submodules are
>  initalized and updated.
>
>* The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1"
>  argument to skip extracting the file that is downloaded (e.g., for
>  self-extracting shell installers or ".msi" files).
>
>* The "ExternalProject" module now uses "TLS_VERIFY" when fetching
>  from git repositories.
>
>* The "FindBLAS" and "FindLAPACK" modules learned to support
>  OpenBLAS.
>
>* The "FindCUDA" module learned to find the "cublas_device" library.
>
>* The "FindGTest" module "gtest_add_tests" function now causes CMake
>  to automatically re-run when test sources change so that they can be
>  re-scanned.
>
>* The "FindLTTngUST" module was introduced to find the LTTng-UST
>  library.
>
>* The "FindPkgConfig" module learned to optionally create imported
>  targets for the libraries it has found.
>
>* The "FindProtobuf" module learned to provide a "Protobuf_VERSION"
>  variable and check the version number requested in a
>  "find_package()" call.
>
>* The "InstallRequiredSystemLibraries" module learned a new
>  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
>  of the Windows Universal CRT libraries with Visual Studio 2015.
>
>
>Platforms
>---------
>
>* The Clang compiler is now supported on CYGWIN.
>
>* Support was added for the Bruce C Compiler with compiler id
>  "Bruce".
>
>
>CTest
>-----
>
>* The "ctest_update()" command now looks at the
>  "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules
>  should be updated or not before updating.
>
>* The "ctest_update()" command will now synchronize submodules on an
>  update. Updates which add submodules or change a submodule's URL
>  will now be pulled properly.
>
>
>CPack
>-----
>
>* The "CPackDeb" module learned how to handle "$ORIGIN" in
>  "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used
>  for dependency auto detection.
>
>* The "CPackDeb" module learned how to generate "DEBIAN/shlibs"
>  contorl file when package contains shared libraries.
>
>* The "CPackDeb" module learned how to generate "DEBIAN/postinst"
>  and "DEBIAN/postrm" files if the package installs libraries in
>  ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/").
>
>* The "CPackDeb" module learned how to generate dependencies between
>  Debian packages if multi-component setup is used and
>  "CPACK_COMPONENT_<compName>_DEPENDS" variables are set. For backward
>  compatibility this feature is disabled by default. See
>  "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS".
>
>* The "CPackDeb" module learned how to set custom package file names
>  including how to generate properly-named Debian packages:
>
><PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
>
>  For backward compatibility this feature is disabled by default. See
>  "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN_<COMPONENT>_FILE_NAME".
>
>* The "CPackDeb" module learned how to set the package release
>  number ("DebianRevisionNumber" in package file name when used in
>  combination with "DEB-DEFAULT" value set by
>  "CPACK_DEBIAN_FILE_NAME").  See "CPACK_DEBIAN_PACKAGE_RELEASE".
>
>* The "CPackDeb" module learned how to set the package architecture
>  per-component.  See "CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE".
>
>* The "CPackDMG" module learned a new option to tell the CPack
>  "DragNDrop" generaor to skip the "/Applications" symlink. See the
>  "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable.
>
>* The "CPackIFW" module gained a new "cpack_ifw_update_repository()"
>  command to update a QtIFW-specific repository from a remote
>  repository.
>
>* The "CPackRPM" module learned how to set RPM "dist" tag as part of
>  RPM "Release:" tag when enabled (mandatory on some Linux
>  distributions for e.g. on Fedora). See
>  "CPACK_RPM_PACKAGE_RELEASE_DIST".
>
>* The "CPackRPM" module learned how to set default values for owning
>  user/group and file/directory permissions of package content. See
>  "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP",
>  "CPACK_RPM_DEFAULT_FILE_PERMISSIONS",
>  "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component
>  counterparts.
>
>* The "CPackRPM" module learned how to set user defined package file
>  names, how to specify that rpmbuild should decide on file name
>  format as well as handling of multiple rpm packages generated by a
>  single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and
>  "CPACK_RPM_<component>_PACKAGE_NAME".
>
>* The "CPackRPM" module learned how to correctly handle symlinks
>  that are pointing outside generated packages.
>
>
>Other
>-----
>
>* The "Compile Features" functionality is now aware of features
>  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
>  platforms.
>
>
>Deprecated and Removed Features
>===============================
>
>* The "CMakeForceCompiler" module and its macros are now deprecated.
>  See module documentation for an explanation.
>
>* The "find_library()", "find_path()", and "find_file()" commands no
>  longer search in installation prefixes derived from the "PATH"
>  environment variable on non-Windows platforms.  This behavior was
>  added in CMake 3.3 to support Windows hosts but has proven
>  problematic on UNIX hosts. Users that keep some "<prefix>/bin"
>  directories in the "PATH" just for their tools do not necessarily
>  want any supporting "<prefix>/lib" directories searched.  One may
>  set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of
>  prefixes that are to be searched.
>
>* The "Visual Studio 7 .NET 2003" generator is now deprecated and
>  will be removed in a future version of CMake.
>
>* The "Visual Studio 7" generator (for VS .NET 2002) has been
>  removed. It had been deprecated since CMake 3.3.
>
>* The "Visual Studio 6" generator has been removed. It had been
>  deprecated since CMake 3.3.
>
>
>Other Changes
>=============
>
>* The precompiled OS X binary provided on "cmake.org" now requires
>  OS X 10.7 or newer.
>
>* On Linux and FreeBSD platforms, when building CMake itself from
>  source and not using a system-provided libcurl, OpenSSL is now used
>  by default if it is found on the system.  This enables SSL/TLS
>  support for commands supporting network communication via "https",
>  such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()".
>
>* The "cmake(1)" "--build" command-line tool now rejects multiple
>  "-- target" options with an error instead of silently ignoring all
>  but the last one.
>
>* "AUTOMOC" now diagnoses name collisions when multiple source files
>  in different directories use "#include <moc_foo.cpp>" with the same
>  name (because the generated "moc_foo.cpp" files would collide).
>
>* The "FindBISON" module "BISON_TARGET" macro now supports special
>  characters by passing the "VERBATIM" option to internal
>  "add_custom_command()" calls.  This may break clients that added
>  escaping manually to work around the bug.
>
>* The "FindFLEX" module "FLEX_TARGET" macro now supports special
>  characters by passing the "VERBATIM" option to internal
>  "add_custom_command()" calls.  This may break clients that added
>  escaping manually to work around the bug.
>
>* The "FindProtobuf" module input and output variables were all
>  renamed from "PROTOBUF_" to "Protobuf_" for consistency with other
>  find modules. Input variables of the old case will be honored if
>  provided, and output variables of the old case are always provided.
>
>* The "CPackRPM" module now supports upper cased component names in
>  per component CPackRPM specific variables. E.g. component named
>  "foo" now expects component specific variable to be
>  "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected
>  "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in
>  variables is compatible with convention used for other CPack
>  variables. For back compatibility old format of variables is still
>  valid and preferred if both versions of variable are set, but the
>  preferred future use is upper cased component names in variables.
>  New variables that will be added to CPackRPM in later versions will
>  only support upper cased component variable format.
>
>----------------------------------------------------------------------------
>Changes made since CMake 3.6.0-rc3:
>
>Bartosz Kosiorek (1):
>      Help: Describe VERSION and SOVERSION meanings for Mach-O binaries
>
>Ben Boeckel (1):
>      ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files
>
>Brad King (2):
>      Revert "try_compile: Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes"
>      CMake 3.6.0-rc4
>
>Gregor Jasny (1):
>      Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)
>
>Robert Maynard (5):
>      FindHDF5: correctly add lang to each component target name.
>      FindHDF5: Handle HDF5 builds with non-suffixed components
>FindHDF5: When component targets not found fallback to compiler
>wrappers
>      FindHDF5: cache the correct path to the high level libraries
>      FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake
>
>Rolf Eike Beer (1):
>      GetPrerequisites: fix typo in comment

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake 3.6.0-rc4 now ready for testing!

Brad King
On 06/29/2016 05:05 PM, Hendrik Sattler wrote:
>> * The "InstallRequiredSystemLibraries" module learned a new
>>  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
>>  of the Windows Universal CRT libraries with Visual Studio 2015.
>  
> Maybe the help should note that this is only needed when targeting
> WindowsXP.

It is also useful for deploying to Windows 7 machines that have
not had updates installed to provide the UCRT libraries.  I've
updated the documentation to show Windows XP as an example:

 InstallRequiredSystemLibraries: Document UCRT option use case
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dab3ccf2

>> * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
>>  use by toolchain files to specify platform-specific variables that
>>  must be propagated by the "try_compile()" command into test
>>  projects.
>
> Can someone please add an example to the help.

Done:

 Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c05d240e

> E.g. I tried to make the initial try_compile() to respect my
> CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file...

CMAKE_CXX_FLAGS_INIT is not documented for use in a toolchain file.
It is used internally by platform modules.

> I really have to use CXXFLAGS environment variable which feels clumsy.
> It's that really the only reliable way to define compiler arguments
> like -mcpu= for all compiler invocations?

It is one way.  Another way is to set the cache entry directly:

  set(CMAKE_CXX_FLAGS "-mcpu=..." CACHE STRING "C++ flags")

Note that CMAKE_CXX_FLAGS is propagated by try_compile automatically.
The above two approaches are actually just trying to get a toolchain
file to have a say in the initial CMAKE_CXX_FLAGS cache entry value
of the main project.

-Brad

--

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
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing!

Chaos Zhang
In reply to this post by Robert Maynard
Thanks a lot for your hard working, thus we can benefit from cmake! :-) Best regard, chao
Robert Maynard wrote
I am proud to announce the fourth CMake 3.6 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc3: Bartosz Kosiorek (1): Help: Describe VERSION and SOVERSION meanings for Mach-O binaries Ben Boeckel (1): ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files Brad King (2): Revert "try_compile: Honor CMAKE__FLAGS_ changes" CMake 3.6.0-rc4 Gregor Jasny (1): Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162) Robert Maynard (5): FindHDF5: correctly add lang to each component target name. FindHDF5: Handle HDF5 builds with non-suffixed components FindHDF5: When component targets not found fallback to compiler wrappers FindHDF5: cache the correct path to the high level libraries FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake Rolf Eike Beer (1): GetPrerequisites: fix typo in comment -- 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake 3.6.0-rc4 now ready for testing!

Hendrik Sattler
In reply to this post by Brad King

Zitat von Brad King <[hidden email]>:

> On 06/29/2016 05:05 PM, Hendrik Sattler wrote:
>>> * The "InstallRequiredSystemLibraries" module learned a new
>>>  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
>>>  of the Windows Universal CRT libraries with Visual Studio 2015.
>>
>> Maybe the help should note that this is only needed when targeting
>> WindowsXP.
>
> It is also useful for deploying to Windows 7 machines that have
> not had updates installed to provide the UCRT libraries.  I've
> updated the documentation to show Windows XP as an example:
>
>  InstallRequiredSystemLibraries: Document UCRT option use case
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dab3ccf2

Thanks.

>>> * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
>>>  use by toolchain files to specify platform-specific variables that
>>>  must be propagated by the "try_compile()" command into test
>>>  projects.
>>
>> Can someone please add an example to the help.
>
> Done:
>
>  Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c05d240e
>
>> E.g. I tried to make the initial try_compile() to respect my
>> CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file...
>
> CMAKE_CXX_FLAGS_INIT is not documented for use in a toolchain file.
> It is used internally by platform modules.
>
>> I really have to use CXXFLAGS environment variable which feels clumsy.
>> It's that really the only reliable way to define compiler arguments
>> like -mcpu= for all compiler invocations?
>
> It is one way.  Another way is to set the cache entry directly:
>
>   set(CMAKE_CXX_FLAGS "-mcpu=..." CACHE STRING "C++ flags")
>
> Note that CMAKE_CXX_FLAGS is propagated by try_compile automatically.
> The above two approaches are actually just trying to get a toolchain
> file to have a say in the initial CMAKE_CXX_FLAGS cache entry value
> of the main project.

The the following code in CMakeCXXInformation.cmake does nothing
--------------------snip--------------------
# add the flags to the cache based
# on the initial values computed in the platform/*.cmake files
# use _INIT variables so that this only happens the first time
# and you can set these flags in the cmake cache
set(CMAKE_CXX_FLAGS_INIT "$ENV{CXXFLAGS} ${CMAKE_CXX_FLAGS_INIT}")
# avoid just having a space as the initial value for the cache
if(CMAKE_CXX_FLAGS_INIT STREQUAL " ")
   set(CMAKE_CXX_FLAGS_INIT)
endif()
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING
      "Flags used by the compiler during all build types.")
--------------------snip--------------------

So each and every toolchain file shall also take care of the  
environment variable?
How about CMAKE_CXX_FLAGS_INIT set by other module files? Ok, only 3  
real users in CMake's module folder.

And VERY IMPORTANT: the toolchain file MUST make those variables CACHE  
variables, else it will not work (at least CMAKE_CXX_FLAGS is only  
propagated, then).

Thanks...

Hendrik



--

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
Reply | Threaded
Open this post in threaded view
|

Re: initializing flags from toolchain files (was: CMake 3.6.0-rc4 now ready for testing!)

Brad King
On 07/01/2016 04:06 AM, Hendrik Sattler wrote:
> So each and every toolchain file shall also take care of the  
> environment variable?
> How about CMAKE_CXX_FLAGS_INIT set by other module files?

Currently the only way to get CMake's default flags for the
platform and also add one's own flags from a toolchain file
is to set the environment variable.  I've now made changes
(for CMake 3.7) to enable use of CMAKE_CXX_FLAGS_INIT for this:

 Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT set in toolchain files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a66004be

Also, CMake 3.7 will add a new policy to allow the per-config flags
to be used in try_compile too:

 try_compile: Add policy CMP0066 to honor CMAKE_<LANG>_FLAGS_<CONFIG>
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d582c23a

-Brad
--

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