[CMake] [ANNOUNCE] CMake mailing list now closed
As was previously announced, CMake is stopping mailing list usage, and has transitioned to a Discourse forum (https://discourse.cmake.org). While new posts to the mailing list are disabled, all previous discussion will be archived so that the knowledge can be searched going forward. Hopefully I will see you all on discourse.cmake.org! -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.17.0 available for download
I am happy to announce that CMake 3.17.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.17 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.17/release/3.17.html Some of the more significant changes in CMake 3.17 are: * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where "find_*" commands search. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra "find_*" call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL’s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead, it expects ".dll.a" import libraries to be available. * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. CMake 3.17 Release Notes Changes made since CMake 3.16 include the following. New Features Generators -- * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * Visual Studio Generators for VS 2010 and above now support specifying the "VCTargetsPath" value for project files in "CMAKE_GENERATOR_TOOLSET" setting. * Visual Studio Generators for VS 2010 and above learned to support .NET Standard and .NET Core. See the "DOTNET_TARGET_FRAMEWORK" target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK" variable. Languages - * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". Compilers - * The IBM XL Fortran compiler is now supported by the "Ninja" generator. Command-Line * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where "find_*" commands search. * "cmake(1)" gained a "--trace-format" command-line option that can be used to set the "--trace" output format. Currently, the old human readable and the new JSON format are supported. The new JSON format is easier to parse automatically than the existing format. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. Commands * The "add_custom_command()" command learned to interpret paths in "DEPENDS" arguments that are specified relative to the current binary directory. * The "foreach()" command learned a new "ZIP_LISTS" option
[CMake] [ANNOUNCE] CMake 3.17.0-rc3 is ready for testing
I am proud to announce the third CMake 3.17 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.17 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.17/release/3.17.html Some of the more significant changes in CMake 3.17 are: * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where "find_*" commands search. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra "find_*" call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL’s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead, it expects ".dll.a" import libraries to be available. * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. CMake 3.17 Release Notes Changes made since CMake 3.16 include the following. New Features Generators -- * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * Visual Studio Generators for VS 2010 and above now support specifying the "VCTargetsPath" value for project files in "CMAKE_GENERATOR_TOOLSET" setting. * Visual Studio Generators for VS 2010 and above learned to support .NET Standard and .NET Core. See the "DOTNET_TARGET_FRAMEWORK" target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK" variable. Languages - * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". Compilers - * The IBM XL Fortran compiler is now supported by the "Ninja" generator. Command-Line * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where "find_*" commands search. * "cmake(1)" gained a "--trace-format" command-line option that can be used to set the "--trace" output format. Currently, the old human readable and the new JSON format are supported. The new JSON format is easier to parse automatically than the existing format. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. Commands * The "add_custom_command()" command learned to interpret paths in "DEPENDS" arguments that are specified relative to the current binary directory. * The "foreach()" command learned a new "ZIP_LISTS" option to iterate
[CMake] [ANNOUNCE] CMake 3.16.5 available for download
We are pleased to announce that CMake 3.16.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.16.5 since 3.16.4: Brad King (5): libarchive: Fix WideCharToMultiByte output buffer size libarchive: Add support for UTF-8 locale on Windows Propagate backtraces from LINK_LIBRARIES through to link line items Help: Update CMake 3.16 release notes for 3.16.5 CMake 3.16.5 Francisco Facioni (1): Ninja: Do not use nvcc response files with non-nvcc tools Kyle Edwards (1): install: Fix regression when using default destinations Marc Chevrier (2): FindPython: Mark non-public cache entries INTERNAL in CMake 3.16 FindPython: Do not cache computed result variables in CMake 3.16 Rolf Eike Beer (1): FindPkgConfig: set policies CMP0054 and CMP0057 to new -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.17.0-rc2 is ready for testing
I am proud to announce the second CMake 3.17 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.17 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.17/release/3.17.html Some of the more significant changes in CMake 3.17 are: * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL’s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead it expects ".dll.a" import libraries to be available. * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. CMake 3.17 Release Notes Changes made since CMake 3.16 include the following. New Features Generators -- * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * Visual Studio Generators for VS 2010 and above now support specifying the "VCTargetsPath" value for project files in "CMAKE_GENERATOR_TOOLSET" setting. * Visual Studio Generators for VS 2010 and above learned to support .NET Standard and .NET Core. See the "DOTNET_TARGET_FRAMEWORK" target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK" variable. Languages - * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". Compilers - * The IBM XL Fortran compiler is now supported by the "Ninja" generator. Command-Line * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * "cmake(1)" gained a "--trace-format" command-line option that can be used to set the "--trace" output format. Currently, the old human readable and the new JSON format are supported. The new JSON format is easier to parse automatically, than the existing format. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. Commands * The "add_custom_command()" command learned to interpret paths in "DEPENDS" arguments that are specified relative to the current binary directory. * The "foreach()" learned a new option "ZIP_LISTS" to iterate over multiple
[CMake] [REMINDER] CMake transition to discourse
Reminder the CMake Discourse forum ( https://discourse.cmake.org ) is the preferred location for CMake questions and discussions. The current mailman-based mailing lists will be disabled in April 2020, and their archives will remain available after that. Reminder for those who prefer email over web forums, the Forum Help page includes instructions to participate in the forum purely via email. Creating topics in the forum via email (and receiving replies) is supported *with or without* registering a user account. -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.17.0-rc1 is ready for testing
I am proud to announce the first CMake 3.17 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.17 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.17/release/3.17.html Some of the more significant changes in CMake 3.17 are: * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL’s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead it expects ".dll.a" import libraries to be available. * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. CMake 3.17 Release Notes Changes made since CMake 3.16 include the following. New Features Generators -- * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * Visual Studio Generators for VS 2010 and above now support specifying the "VCTargetsPath" value for project files in "CMAKE_GENERATOR_TOOLSET" setting. * Visual Studio Generators for VS 2010 and above learned to support .NET Standard and .NET Core. See the "DOTNET_TARGET_FRAMEWORK" target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK" variable. Languages - * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". Compilers - * The IBM XL Fortran compiler is now supported by the "Ninja" generator. Command-Line * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * "cmake(1)" gained a "--trace-format" command-line option that can be used to set the "--trace" output format. Currently, the old human readable and the new JSON format are supported. The new JSON format is easier to parse automatically, than the existing format. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. Commands * The "add_custom_command()" command learned to interpret paths in "DEPENDS" arguments that are specified relative to the current binary directory. * The "foreach()" learned a new option "ZIP_LISTS" to iterate over multiple
[CMake] [ANNOUNCE] CMake 3.16.4 available for download
We are pleased to announce that CMake 3.16.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.16.4 since 3.16.3: Brad King (6): ASM_MASM: Populate MSVC runtime library abstraction table VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs AIX: Restore pre-3.16 undocumented method to suppress exports with XL Android: Fix binutils selection with NDK r19+ unified toolchain VS: Do not use native unity builds on VS 2017 versions less than 15.8 CMake 3.16.4 Kyle Edwards (3): file(GET_RUNTIME_DEPENDENCIES): Tolerate empty list arguments Help: Add more variable documentation to FindMPI CPack: Fix regression in Deb description -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.15.7 available for download
We are pleased to announce that CMake 3.15.7 is now available for download.
Please use the latest release from our download page:
https://cmake.org/download/
Thanks for your support!
-
Changes in 3.15.7 since 3.15.6:
Brad King (4):
IRSL: Install msvcp140_{1,2,codecvt_ids}.dll if available
ASM_MASM: Populate MSVC runtime library abstraction table
VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs
CMake 3.15.7
Robert Maynard (1):
CUDA: Do not device link if target has no CUDA usage
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community. For more
information on each offering, please visit https://cmake.org/services
Visit other Kitware open-source projects at https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.16.3 available for download
We are pleased to announce that CMake 3.16.3 is now available for download.
Please use the latest release from our download page:
https://cmake.org/download/
Thanks for your support!
-
Changes in 3.16.3 since 3.16.2:
Ashley Whetter (1):
FindOpenSSL: Fix ordering of dependency link flags
Brad King (3):
GNUtoMS: Add search path for VS 2019 environment scripts
IRSL: Install msvcp140_{1,2,codecvt_ids}.dll if available
CMake 3.16.3
Cristian Adam (4):
ObjC: Add _COMPILE_LAUNCHER support
ObjC: Add VISIBLITY_INLINES_HIDDEN support
Unity Build: include language in generated source file name
PCH: No repeated path for internal generated PCH files (MSVC case)
Kyle Edwards (2):
CTest: Improve error handling when reading resource spec file
CPack: Fix regression in DEB generator description
Marc Chevrier (3):
FindPython*: Fix erroneous target properties setting
macOS: Add support for new Xcode 11 frameworks directory
FindPython: ensure new Xcode framework for Python3 is detected
Miro Hrončok (1):
FindPython: Add support for version 3.9
Neil Carlson (1):
Fortran: Add support for NAG Fortran submodules
Pavel Liavonau (1):
VS: Add Fortran link flag table entries for /OPT:*
Robert Maynard (1):
CUDA: Do not device link if target has no CUDA usage
Sebastian Holtermann (1):
Autogen: Enable SKIP_UNITY_BUILD_INCLUSION on AUTORCC generated files
Silvio Traversaro (2):
FindMatlab: add R2019a and R2019b MATLAB_VERSIONS_MAPPING
FindMatlab: in matlab_add_mex use the correct version file
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community. For more
information on each offering, please visit https://cmake.org/services
Visit other Kitware open-source projects at https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] [ANNOUNCE] CMake Discourse forum now available
A reminder that CMake is transitioning to Discouse, and by the end of March 2020 the mailing lists will be read-only, and the archives will remain available after that. The Discourse forum for the CMake community is: https://discourse.cmake.org Discourse offers users more control over their level of participation, allowing them to subscribe or unsubscribe by category or individual topic. Users may choose to participate by web forum, email, or both. To get started, see our Forum Help page: https://discourse.cmake.org/faq User accounts may be created using Email Registration, a GitHub Account, or a Google Account. For those who prefer email over web forums, the Forum Help page includes instructions to participate in the forum purely via email. Creating topics in the forum via email (and receiving replies) is supported *with or without* registering a user account. User accounts may be configured to receive email notifications for forum activity at several levels of granularity, or to receive email notifications for all activity like a mailing list. On Tue, Nov 5, 2019 at 12:13 PM Robert Maynard wrote: > > A Discourse forum is now available for the CMake community: > > https://discourse.cmake.org > > Discourse offers users more control over their level of participation, > allowing them to subscribe or unsubscribe by category or individual topic. > Users may choose to participate by web forum, email, or both. > > To get started, see our Forum Help page: > > https://discourse.cmake.org/faq > > User accounts may be created using Email Registration, a GitHub Account, or a > Google Account. > > For those who prefer email over web forums, the Forum Help page includes > instructions to participate in the forum purely via email. Creating topics in > the forum via email (and receiving replies) is supported *with or without* > registering a user account. User accounts may be configured to receive email > notifications for forum activity at several levels of granularity, or to > receive email notifications for all activity like a mailing list. > > To facilitate a transition period, the current mailman-based mailing lists > will remain active until at least the end of March 2020, and their archives > will remain available after that. > > See you on discourse.cmake.org! -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.16.2 available for download
We are pleased to announce that CMake 3.16.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.16.2 since 3.16.1: Brad King (6): VS: Fix support for v142 toolset minor versions in VS 16.5+ FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX FindBoost: Add support for Boost 1.72 Autogen: Revert processing of .hh files for compatibility FindLAPACK: Fix support for LAPACK symbols inside BLAS libraries CMake 3.16.2 Cristian Adam (1): PCH: Append pch header file to list of forced include files Michael Dickens (1): Tests: Fix testCTestResourceSpec struct initialization for some compilers -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.15.6 available for download
We are pleased to announce that CMake 3.15.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.6 since 3.15.5: Alexander Grund (1): Check for support before adding bigtoc linker flag Ben Boeckel (1): FindPostgreSQL: support version encoding used in pre-10 releases Brad King (4): CMakeParseImplicitIncludeInfo: Remove all CR chars from compiler output VS: Fix support for v142 toolset minor versions in VS 16.5+ FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX CMake 3.15.6 Deniz Bahadir (1): FindBoost: Prevent warning due to new meta-component "ALL" of Boost 1.73 Markus Mittendrein (1): FindGTK2: Add harfbuzz to GTK2_INCLUDE_DIRS -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] ANNOUNCE] CMake 3.16.1 available for download
We are pleased to announce that CMake 3.16.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.16.1 since 3.16.0: Alexander Grund (2): bootstrap: Add target_link_options command Check for support before adding bigtoc linker flag Ben Boeckel (1): TestDriver: ignore strcpy call Brad King (2): FindThreads: Restore hard-coded '-l' flag on library name CMake 3.16.1 Cristian Adam (5): PCH: Do not add #pragma system_header for Xcode generator Unity/PCH: Skip more target types when adding automatic sources Unity: Generic source file handling for all generators Unity: Proper handling of object libraries PCH: Use the target's PREFIX for building the pdb file name Kyle Edwards (1): CTest Resource Allocation: Add test for spec file with no version Tobias Taschner (1): FindwxWidgets: Add support for 3.1.3 on macOS -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.16.0 available for download
I am happy to announce that CMake 3.16.0 is now available for download at:
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
resource requirements for each test. See Resource Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
Re: [cmake-developers] [ANNOUNCE] CMake Discourse forum now available
> To facilitate a transition period, the current mailman-based mailing lists > will remain active until at least the end of March 2020, and their archives > will remain available after that. This transition period was announced both on the users list and here on the developers list. Since the developers list is fairly low traffic and there are not currently any active threads, we've decided to close this list now. Please post to the CMake Discourse "Development" category instead: https://discourse.cmake.org/c/development See you on discourse.cmake.org! -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] Link options not transitive
You should report this on the CMake issue tracker: https://gitlab.kitware.com/cmake/cmake/issues/ On Sat, Nov 23, 2019 at 12:03 PM Martin Krošlák wrote: > > Hi, > > I have recently encountered what I believe might be a bug, where > INTERFACE_LINK_OPTIONS are not carried over static libraries. > Following is the simplest CMakeLists.txt that demonstrates the > problem: > > cmake_minimum_required(VERSION 3.16) > project(LinkOptionsNotTransitive) > add_library(A SHARED A.cpp) > add_library(B STATIC B.cpp) > add_executable(C C.cpp) > target_link_options(A INTERFACE "/DELAYLOAD:A.dll") > target_link_libraries(B PRIVATE A) > target_link_libraries(C PRIVATE B) > > I tested this with Visual Studio 2017 generator and both cmake 3.15.4 > and 3.16.0-rc4, with the same result. > > When inspecting generated solution, C is linking both A.lib and B.lib > (as it should), but /DELAYLOAD flag is not applied to it. If B has > PUBLIC dependency on A, then /DELAYLOAD flag is also correctly carried > over. I get the impression that target_link_options behaves as eg. > target_include_directories, which are not carried over PRIVATE > dependencies. Given that these are linker options, I would expect them > to follow same rules as target_link_libraries, which will carry over > until nearest linker invocation. Is there any reason for this > inconsistency, or is it just a bug and if so, what would be the best > way to report it? > > -- > Sincerely, > Martin Krošlák > -- > > Powered by kitware.com/cmake > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit https://cmake.org/services > > Visit other Kitware open-source projects at https://www.kitware.com/platforms > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > This mailing list is deprecated in favor of https://discourse.cmake.org -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] [ANNOUNCE] CMake 3.16.0-rc4 is ready for testing
I am proud to announce the fourth CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
resource requirements for each test. See Resource Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
[cmake-developers] [ANNOUNCE] CMake Discourse forum now available
A Discourse forum is now available for the CMake community: https://discourse.cmake.org Discourse offers users more control over their level of participation, allowing them to subscribe or unsubscribe by category or individual topic. Users may choose to participate by web forum, email, or both. To get started, see our Forum Help page: https://discourse.cmake.org/faq User accounts may be created using Email Registration, a GitHub Account, or a Google Account. For those who prefer email over web forums, the Forum Help page includes instructions to participate in the forum purely via email. Creating topics in the forum via email (and receiving replies) is supported *with or without* registering a user account. User accounts may be configured to receive email notifications for forum activity at several levels of granularity, or to receive email notifications for all activity like a mailing list. To facilitate a transition period, the current mailman-based mailing lists will remain active until at least the end of March 2020, and their archives will remain available after that. See you on discourse.cmake.org! -- 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-developers
[CMake] [ANNOUNCE] CMake Discourse forum now available
A Discourse forum is now available for the CMake community: https://discourse.cmake.org Discourse offers users more control over their level of participation, allowing them to subscribe or unsubscribe by category or individual topic. Users may choose to participate by web forum, email, or both. To get started, see our Forum Help page: https://discourse.cmake.org/faq User accounts may be created using Email Registration, a GitHub Account, or a Google Account. For those who prefer email over web forums, the Forum Help page includes instructions to participate in the forum purely via email. Creating topics in the forum via email (and receiving replies) is supported *with or without* registering a user account. User accounts may be configured to receive email notifications for forum activity at several levels of granularity, or to receive email notifications for all activity like a mailing list. To facilitate a transition period, the current mailman-based mailing lists will remain active until at least the end of March 2020, and their archives will remain available after that. See you on discourse.cmake.org! -- 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-developers] [ANNOUNCE] CMake 3.16.0-rc3 is ready for testing
I am proud to announce the third CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
[CMake] [ANNOUNCE] CMake 3.16.0-rc3 is ready for testing
I am proud to announce the third CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
[cmake-developers] [ANNOUNCE] CMake 3.15.5 available for download
We are pleased to announce that CMake 3.15.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.5 since 3.15.4: Alan W. Irwin (1): Help: Fix COMPILE_LANG_AND_ID genex example Brad King (7): VS: Fix support for v142 toolset minor versions Xcode: Restore CMAKE_XCODE_GENERATE_SCHEME for custom targets VS: Tell VS 16.4 not to verify CMake-provided custom command outputs VS: Add toolset v142 CSharp flag table IRSL: Prefer MSVC runtime libraries from newest toolset first IRSL: Install vcruntime140_1.dll if available CMake 3.15.5 -- 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-developers
[CMake] [ANNOUNCE] CMake 3.15.5 available for download
We are pleased to announce that CMake 3.15.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.5 since 3.15.4: Alan W. Irwin (1): Help: Fix COMPILE_LANG_AND_ID genex example Brad King (7): VS: Fix support for v142 toolset minor versions Xcode: Restore CMAKE_XCODE_GENERATE_SCHEME for custom targets VS: Tell VS 16.4 not to verify CMake-provided custom command outputs VS: Add toolset v142 CSharp flag table IRSL: Prefer MSVC runtime libraries from newest toolset first IRSL: Install vcruntime140_1.dll if available CMake 3.15.5 -- 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-developers] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing
I am proud to announce the second CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
[CMake] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing
I am proud to announce the second CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
Re: [CMake] Custom installation of cmake
The easiest way is to specify the custom compiler via the CC and CXX environment variables. On Sat, Oct 19, 2019 at 2:19 PM Mahmood Naderan via CMake wrote: > > OK and how about custom installation path of cmake? > > > Regards, > Mahmood > > > On Saturday, October 19, 2019, 4:44:28 PM GMT+3:30, 15 knots > wrote: > > > What worked for me, is to add 'ools/gcc-7.1.0/bin/' in front of the > PATh environment variable for the time cmake is invoked. E.g from > bash. > PATH=tools/gcc-7.1.0/bin/;$PATH cmake -G ... > > Martin > > -- > > 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] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)
Hi Paul, As another reference point, I verified that -DCMAKE_UNITY_BUILD=ON works with the VTK-m ( https://gitlab.kitware.com/vtk/vtk-m ) project. I only verified using a clean CMake 3.16 build directory. On Thu, Oct 10, 2019 at 6:43 PM Paul Smith wrote: > > On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: > > * The "UNITY_BUILD" target property was added to tell generators to > > batch include source files for faster compilation times. > > Are there any instructions on how to make this work? I tried this: > > cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON . > > Then ran "make". The output showed I had just as many output .o files > as input .cpp files and that make ran one compile command per .cpp > file. > > Is there something else I need to do to enable unity builds in my cmake > files, than just give the above option? The docs imply that the above > is all that's needed. > > Cheers! > > -- > > 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
[CMake] [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing
I am proud to announce the first CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One
Re: [CMake] [EXTERNAL] Re: CMake and Ninja, RERUN_CMAKE useless?
If you want to do a clean rebuild you can do the following: ninja clean or cmake --build --target clean ninja or cmake --build -j N On Wed, Oct 9, 2019 at 12:00 PM Nagurne, James wrote: > > That's the piece of the puzzle I was missing. Thank you! > > Yes, I had deleted the cache because I thought that would force a complete > regeneration. I'm using a rather complicated system of ExternalProjects > (LLVM), so I figured it was the quickest way to essentially force cmake to > start from the beginning and reload those cache files without invalidating > and forcing a rebuild of the executables and libraries I had already built > > Is there a way to do what I was looking for? I wouldn't be surprised if there > wasn't, since removing those very fundamental building blocks might as well > just be an rm -rf ./* > > JB > > -Original Message- > From: Robert Maynard [mailto:robert.mayn...@kitware.com] > Sent: Wednesday, October 9, 2019 7:16 AM > To: Nagurne, James > Cc: cmake@cmake.org > Subject: [EXTERNAL] Re: [CMake] CMake and Ninja, RERUN_CMAKE useless? > > The default generator and all other associated information ( '-D' ) is > kept in the CMakeCache.txt file in the root of the build directory. > The execution of `cmake -S -B ` will reload > this cache before doing anything else. Have you verified that your > build directory hasn't deleted this file? > > On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake > wrote: > > > > Hi all, > > > > > > > > My question comes from a Ninja generator build system, and is specifically > > about an internal rule generated by cmake. > > > > What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja > > generator? > > > > > > > > In the current repo, the only reference to this rule is in > > WriteTargetRebuildManifest here > > > > At line 1285, the rule is written out, seemingly as-is. > > > > > > > > According to lines 1274 to 1284, the only actual behavior of this command, > > which is executed whenever the source CMakeLists.txt file, files included > > from the CMakeLists, and some other CMake installation files change, is: > > > > cmake -S -B > > > > > > > > This seems completely insufficient for “re-running” cmake. The most obvious > > flaw is the absence of the generator. When I’ve seen this rule fire, my > > Ninja build system adds a useless Makefile to the build system, and then > > (hopefully) continues building as if nothing had been done at all, without > > so much as inspecting that Makefile. > > > > > > > > What about command-line arguments like -D? > > > > > > > > Am I missing the purpose of this rule or potentially doing something > > non-standard? The reason I send an email is because this behavior is > > sending my project into a cmake loop where it detects build.ninja is out of > > date, re-runs cmake to generate a Makefile instead of a ninja build system, > > and then infinitely repeats because it never actually re-ran anything. > > > > > > > > Thanks, > > > > JB > > > > Code Generation > > > > Texas Instruments > > > > -- > > > > 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] CMake and Ninja, RERUN_CMAKE useless?
The default generator and all other associated information ( '-D' ) is kept in the CMakeCache.txt file in the root of the build directory. The execution of `cmake -S -B ` will reload this cache before doing anything else. Have you verified that your build directory hasn't deleted this file? On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake wrote: > > Hi all, > > > > My question comes from a Ninja generator build system, and is specifically > about an internal rule generated by cmake. > > What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja > generator? > > > > In the current repo, the only reference to this rule is in > WriteTargetRebuildManifest here > > At line 1285, the rule is written out, seemingly as-is. > > > > According to lines 1274 to 1284, the only actual behavior of this command, > which is executed whenever the source CMakeLists.txt file, files included > from the CMakeLists, and some other CMake installation files change, is: > > cmake -S -B > > > > This seems completely insufficient for “re-running” cmake. The most obvious > flaw is the absence of the generator. When I’ve seen this rule fire, my Ninja > build system adds a useless Makefile to the build system, and then > (hopefully) continues building as if nothing had been done at all, without so > much as inspecting that Makefile. > > > > What about command-line arguments like -D? > > > > Am I missing the purpose of this rule or potentially doing something > non-standard? The reason I send an email is because this behavior is sending > my project into a cmake loop where it detects build.ninja is out of date, > re-runs cmake to generate a Makefile instead of a ninja build system, and > then infinitely repeats because it never actually re-ran anything. > > > > Thanks, > > JB > > Code Generation > > Texas Instruments > > -- > > 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
[cmake-developers] [ANNOUNCE] CMake 3.15.4 available for download
We are pleased to announce that CMake 3.15.4 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.4 since 3.15.3: Brad King (10): VS: Tell VS 16.4 not to verify SYMBOLIC custom command outputs Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Makefiles: Revert "Make build root targets ... recursive" Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 Help: Add release note for EXCLUDE_FROM_ALL fix in 3.15.4 Help: Mention 3.14.7 EXCLUDE_FROM_ALL fix in 3.15.4 release note CMake 3.15.4 LE GARREC Vincent (1): Help: Document VS 2019 toolset in MSVC_TOOLSET_VERSION -- 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-developers
[CMake] [ANNOUNCE] CMake 3.15.4 available for download
We are pleased to announce that CMake 3.15.4 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.4 since 3.15.3: Brad King (10): VS: Tell VS 16.4 not to verify SYMBOLIC custom command outputs Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Makefiles: Revert "Make build root targets ... recursive" Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 Help: Add release note for EXCLUDE_FROM_ALL fix in 3.15.4 Help: Mention 3.14.7 EXCLUDE_FROM_ALL fix in 3.15.4 release note CMake 3.15.4 LE GARREC Vincent (1): Help: Document VS 2019 toolset in MSVC_TOOLSET_VERSION -- 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-developers] [ANNOUNCE] CMake 3.14.7 available for download
We are pleased to announce that CMake 3.14.7 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.7 since 3.14.6: Brad King (6): Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 CMake 3.14.7 -- 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-developers
[CMake] [ANNOUNCE] CMake 3.14.7 available for download
We are pleased to announce that CMake 3.14.7 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.7 since 3.14.6: Brad King (6): Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 CMake 3.14.7 -- 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-developers] [ANNOUNCE] CMake 3.15.3 available for download
We are pleased to announce that CMake 3.15.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.3 since 3.15.2: Brad King (13): Flang: Implement MSVC runtime library abstraction CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime cmAffinity: Add include for CPU_ZERO on Alpine Linux find_path: Fix crash on empty old-style list of names fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior FindBoost: Simplify conditional block for last known version FindBoost: Remove incorrect 1.70 timer dependency FindBoost: Unwrap compatibility INTERFACE targets for legacy variables FindBoost: Add support for Boost 1.71 FindBoost: Clarify role of legacy variables in warning message FindBoost: Tolerate future Boost INTERFACE libraries CMake 3.15.3 Chuck Atkins (1): CrayPrgEnv: Change default linking mode based on PE version M Furkan USLU (1): ccmake: handle cache entries with empty STRINGS property Marvin Schmidt (1): libarchive: We now require at least version 3.3.3 Robert Maynard (1): FindMPI: Restore MPI__COMPILE_FLAGS and MPI__COMPILE_OPTIONS Sebastian Holtermann (3): Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets Tests: Extend MakeClean test to test various target types Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file -- 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-developers
[CMake] [ANNOUNCE] CMake 3.15.3 available for download
We are pleased to announce that CMake 3.15.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.15.3 since 3.15.2: Brad King (13): Flang: Implement MSVC runtime library abstraction CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime cmAffinity: Add include for CPU_ZERO on Alpine Linux find_path: Fix crash on empty old-style list of names fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior FindBoost: Simplify conditional block for last known version FindBoost: Remove incorrect 1.70 timer dependency FindBoost: Unwrap compatibility INTERFACE targets for legacy variables FindBoost: Add support for Boost 1.71 FindBoost: Clarify role of legacy variables in warning message FindBoost: Tolerate future Boost INTERFACE libraries CMake 3.15.3 Chuck Atkins (1): CrayPrgEnv: Change default linking mode based on PE version M Furkan USLU (1): ccmake: handle cache entries with empty STRINGS property Marvin Schmidt (1): libarchive: We now require at least version 3.3.3 Robert Maynard (1): FindMPI: Restore MPI__COMPILE_FLAGS and MPI__COMPILE_OPTIONS Sebastian Holtermann (3): Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets Tests: Extend MakeClean test to test various target types Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file -- 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.15.0-rc1 is ready for testing
I am proud to announce the first CMake 3.15 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.15 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.15/release/3.15.html Some of the more significant changes in CMake 3.15 are: * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Preliminary support for the "Swift" language was added to the "Ninja" generator. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "FindBoost" module was reworked to expose a more consistent user experience between its “Config” and “Module” modes and with other find modules in general. * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. CMake 3.15 Release Notes Changes made since CMake 3.14 include the following. New Features Generators -- * The "Xcode" generator now supports per-target schemes. See the "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME" target property. * The "Green Hills MULTI" generator has been updated: * It now supports the "add_custom_command()" and "add_custom_target()" commands. * It is now available on Linux. Languages - * Preliminary support for the "Swift" language was added to the "Ninja" generator: * Use the "SWIFTC" environment variable to specify a compiler. * The "Swift_DEPENDENCIES_FILE" target property and "Swift_DEPENDENCIES_FILE" source file property were added to customize dependency files. * The "Swift_MODULE_NAME" target property was added to customize the Swift module name. * The "Swift_DIAGNOSTICS_FILE" source property was added to indicate where to write the serialised Swift diagnostics. The Swift support is experimental, not considered stable, and may change in future releases of CMake. Compilers - * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Support for the Clang-based ARM compiler was added with compiler id "ARMClang". * Support was added for the IAR compiler architectures Renesas RX, RL78, RH850 and Texas Instruments MSP430. * Support was added for the IAR compilers built for Linux (IAR BuildLx). Command-Line * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.
[cmake-developers] [ANNOUNCE] CMake 3.15.0-rc1 is ready for testing
I am proud to announce the first CMake 3.15 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.15 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.15/release/3.15.html Some of the more significant changes in CMake 3.15 are: * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Preliminary support for the "Swift" language was added to the "Ninja" generator. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "FindBoost" module was reworked to expose a more consistent user experience between its “Config” and “Module” modes and with other find modules in general. * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. CMake 3.15 Release Notes Changes made since CMake 3.14 include the following. New Features Generators -- * The "Xcode" generator now supports per-target schemes. See the "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME" target property. * The "Green Hills MULTI" generator has been updated: * It now supports the "add_custom_command()" and "add_custom_target()" commands. * It is now available on Linux. Languages - * Preliminary support for the "Swift" language was added to the "Ninja" generator: * Use the "SWIFTC" environment variable to specify a compiler. * The "Swift_DEPENDENCIES_FILE" target property and "Swift_DEPENDENCIES_FILE" source file property were added to customize dependency files. * The "Swift_MODULE_NAME" target property was added to customize the Swift module name. * The "Swift_DIAGNOSTICS_FILE" source property was added to indicate where to write the serialised Swift diagnostics. The Swift support is experimental, not considered stable, and may change in future releases of CMake. Compilers - * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Support for the Clang-based ARM compiler was added with compiler id "ARMClang". * Support was added for the IAR compiler architectures Renesas RX, RL78, RH850 and Texas Instruments MSP430. * Support was added for the IAR compilers built for Linux (IAR BuildLx). Command-Line * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.
[CMake] Free CMake course during KHQ Summer courses July 22-25 2019
Hi All, This summer between July 22 - 25th Kitware is offering 7 free courses over 3 days at our new headquarters in Albany NY. One of the free courses we will be offering is a full day CMake course on Tuesday July 23rd. Hopefully some of you will be able to attend, and we can meet in person. Sign up for the courses at: https://forms.gle/4Lze8vXrZSyvxWVm6 You can find more information on each course at: https://blog.kitware.com/events/free-vtk-js-girder-tomviz-vtk-paraview-and-cmake-courses-at-kitware-this-summer/ The 4 day overview schedule is: Monday July 22: - VTK.JS: https://kitware.github.io/vtk-js/ - Girder: https://girder.readthedocs.io/en/stable/ Tuesday July 23: - CMake Wednesday July 24: - VTK: https://vtk.org/ - Tomviz: https://tomviz.org/ Thursday July 25 - ParaView: https://www.paraview.org - CMB: https://www.computationalmodelbuilder.org/ -- 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] Question about Variables
The `${ }` syntax deferences the variable, so what you are asking is
if the variable `1_INC_PATH` exists.
What you want is `if(DEFINED WITH_LIB_GLAD_INC_PATH)` to check for the
existence of the variable `WITH_LIB_GLAD_INC_PATH`
On Fri, May 31, 2019 at 4:11 PM Steven Truppe wrote:
>
> Hi everyone,
>
> i'm relative new to cmake (a few weeks now) and i have the following
> problem:
>
>
> set(WITH_LIB_GLAD 1)
>
> IF(DEFINED ${WITH_LIB_GLAD}_INC_PATH)
>
> I try to check if the variable WITH_LIB_GLAD_INC_PATH can be found.
>
>
> best regards!
>
>
>
> --
>
> 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
[cmake-developers] [ANNOUNCE] CMake 3.14.5 available for download
We are pleased to announce that CMake 3.14.5 is now available for download. The Visual Studio 2019 16.1 update introduced a regression in MSBuild's evaluation of custom command dependencies causing them to re-run on every build. CMake 3.14.5 includes a workaround, for more details on the issue see: https://gitlab.kitware.com/cmake/cmake/issues/19303 Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.5 since 3.14.4: Alex Turbov (1): FindBoost: Add compiler features for Boost Contract library Brad King (5): libarchive: avoid b64_encode name conflict with Solaris built-in function FindThreads: Drop incorrect docs about usage with C++ Do not exclude include directories made implicit by CPATH VS: Isolate custom command input/output generation scopes CMake 3.14.5 Frans van Dorsselaer (2): VS: Clarify name of custom commands AdditionalInputs variable VS: De-duplicate custom command dependencies -- 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-developers
[CMake] [ANNOUNCE] CMake 3.14.5 available for download
We are pleased to announce that CMake 3.14.5 is now available for download. The Visual Studio 2019 16.1 update introduced a regression in MSBuild's evaluation of custom command dependencies causing them to re-run on every build. CMake 3.14.5 includes a workaround, for more details on the issue see: https://gitlab.kitware.com/cmake/cmake/issues/19303 Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.5 since 3.14.4: Alex Turbov (1): FindBoost: Add compiler features for Boost Contract library Brad King (5): libarchive: avoid b64_encode name conflict with Solaris built-in function FindThreads: Drop incorrect docs about usage with C++ Do not exclude include directories made implicit by CPATH VS: Isolate custom command input/output generation scopes CMake 3.14.5 Frans van Dorsselaer (2): VS: Clarify name of custom commands AdditionalInputs variable VS: De-duplicate custom command dependencies -- 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] Dependency cycle - why?
I misspoke. I meant that what you want to do with the custom commands
was supported by CMake.
Adding support for extra languages to CMake requires modifications at
the C++ level, if you want full support. Things such as installing,
and generator expressions require C++ level changes.
On Sat, May 25, 2019 at 10:47 AM Eric Noulard wrote:
>
>
>
> Le sam. 25 mai 2019 à 13:51, Bill Somerville a écrit :
>>
>> Hi Robert,
>>
>> thanks for that, the target name change does seem to help but I am still
>> unable to achieve my goal. Here is a simplified example that demonstrates
>> the problem:
>>
>> cmake_minimum_required (VERSION 3.1.0 FATAL_ERROR)
>> project (demo LANGUAGES NONE)
>> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch
>> prog${CMAKE_EXECUTABLE_SUFFIX})
>> add_executable (prog IMPORTED)
>> add_dependencies (prog prog_target)
>> set_target_properties (prog PROPERTIES IMPORTED_LOCATION
>> ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
>> install (TARGETS prog RUNTIME DESTINATION bin)
>>
>> which gives the following error at CMake configuration:
>>
>> CMake Error at CMakeLists.txt:7 (install):
>> install TARGETS given target "prog" which does not exist.
>>
>>
>> -- Configuring incomplete, errors occurred!
>>
>> So the target that 'add_executable(name IMPORTED)' creates is not a real
>> executable target. I can change its properties but the 'install(TARGETS
>> ...)' command thinks it does not exist. Note that a executable target is a
>> very simple demonstration and I understand that I can use 'install(PROGRAM
>> ...)' just about as easily, but when it comes to a shared library it gets a
>> lot more complex when using, exporting, and instlling it, and it seems that
>> IMPORTED targets fall well short of useful when they are actually produced
>> by the current CMake project.
>>
>> I can understand that an IMPORTED target is perhaps not meant to be
>> installable
>
>
> Robert will give his advice on that but I bet IMPORTED target were never
> meant to be drop-in *replacement* of genuine target.
That is correct. Specifically imported targets aren't meant to be
exported or installed. They are meant to represent some item that
already exists on disk, and as such you should install the logic that
constructs the imported targets.
>
> They were meant to ease *reference to* object/lib:executable that are outside
> the build of the project.
> e.g the doc says:
> https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
> "An IMPORTED library target references a library file located outside the
> project"
>
> Nmelly a target that is "already installed somewhere" and that you want to
> reference in your CMake build.
>
>>
>> but if so then your statement that "The goal that you have is fully
>> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
>> foreign tools to make binary targets and wish to have CMake treat them *as
>> if* they were created by supported languages like C, ++, or Fortran. Am I
>> still missing something?
>
>
> My opinion is that IMPORTED target are not designed (as of today) for that
> purpose.
>
> When you want to do what you seem to want you need to either:
> 1) add a "new LANGUAGE" (you seem to be willing to add golang)
> see:
> https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
> and may be: https://github.com/aadidenko/golang-cmake-example (or fork of
> this)
>
> 2) define a set of custom macros that mimic genuine target behaviour.
> may be see: https://github.com/cpconduce/go_cmake
>
> If you want to have a look at existing similar example shippped with CMake,
> have a look at UseJava.cmake module
> (https://cmake.org/cmake/help/latest/module/UseJava.html)
> You'll see that you have
> add_jar, which is similar to add_executable and create a custom target
> and
> install_jar which is similar to install on genuine target but plays with
> target properties and install(FILES...) in order to mimic that.
> see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake
>
> I'm not developing with golang but AFAIK go has a builtin "build system" so
> bringing go as a language in CMake may not be the best option,
> but again I am no Go expert.
>
> The only reference of that kind of thing I found in the CMake mailing list is
> oldish:
> https://cmake.org/pipermail/cmake-developers/2011-August/013715.html
>
> May be adding the support for "install" command for IMPORTED target is doable
> but this seems to be a feature request to be discussed on developer mailing
> list;
> Regards,
> Eric
>
>>
>> Regards
>> Bill Somerville.
>>
>> On 24/05/2019 20:23, Robert Maynard wrote:
>>
>> Hi,
>>
>> The goal that you have is fully supported by CMake. You have just run
>> into a bug in CMake, and you should report this to
>> https://gitlab.kitware.com/cmake/cmake/issues .
>> Basically at a very high level the name out the
Re: [CMake] Dependency cycle - why?
Hi,
The goal that you have is fully supported by CMake. You have just run
into a bug in CMake, and you should report this to
https://gitlab.kitware.com/cmake/cmake/issues .
Basically at a very high level the name out the add_executable target
`callback_generator` is the same as the internal name that CMake is
using for the add_custom_command. This than causes some logic in CMake
(cmTargetTraceDependencies) to incorrectly build another link between
the add_custom_command and your add_executable.
The easiest way to solve this issue is name the add_executable target
to have a different name than the output of your custom command minus
file extension. So maybe something like `callback_generator_exec`
On Fri, May 24, 2019 at 2:02 PM Bill Somerville wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file (MAKE_DIRECTORY ${GOPATH})
>
> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
> set (build_command ${GO} build)
> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
> add_custom_command (OUTPUT ${output}
> COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH}
> CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output}
> ${CMAKE_GO_FLAGS} ${sources}
> DEPENDS ${sources}
> VERBATIM)
> add_custom_target (callback_generator_target DEPENDS
> ${CMAKE_CURRENT_BINARY_DIR}/${output})
> add_executable (callback_generator IMPORTED)
> set_target_properties (callback_generator
> PROPERTIES
> IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
> )
> add_dependencies (callback_generator callback_generator_target)
>
> add_custom_target (server ALL DEPENDS callback_generator)
>
> which gives this error:
>
> >cmake --version
> cmake --version
> cmake version 3.14.3
>
> >cmake -G "MinGW Makefiles" ..\..
> cmake -G "MinGW Makefiles" ..\..
> -- Configuring done
> CMake Error: The inter-target dependency graph contains the following
> strongly connected component (cycle):
> "callback_generator_target" of type UTILITY
> depends on "callback_generator_target" (strong)
> The component contains at least one cycle consisting of strong dependencies
> (created by add_dependencies) that cannot be broken.
>
> The set_target_properties () call seems to be part of the problem but I don't
> understand why.
>
> Regards
> Bill Somerville.
>
> Hi again,
>
> answering my own post since no one has replied. Clearly my question was too
> specific. Let me try again with a more general question. I have tools that
> can generate executables (programs, static libraries, and shared libraries,
> including DLL import libraries on MS Windows). These tools are not directly
> supported by CMake but they are both needed within a project that uses them
> and installs them as the project artefacts. How do I integrate, for example a
> shared library, into a CMake project as if it were produced by a supported
> toolchain like C or C++? The library is produced by an add_custom_target()
> command (not add_custom_command() since the underlying tools do their own
> dependency checking so it is right to run the target commands every build). I
> need to have a target that I can use in target_link_libraries() and
> install(TARGETS ...) just like one would with a CMake generated library made
> with add_library() and programs made with add_executable().
>
> If it helps the tools that are not supported by CMake are the Go language
> build tools. The project builds some Go programs as utilities but the main
> project artefact is a shared library with a C language API built using the
> cgo tools. There are many of C and C++ test programs and example programs as
> well in the project which need to link against the project shared library etc.
>
> Regards
> Bill Somerville.
>
> --
>
> 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
Re: [CMake] Specifying VS 2019 LLVM toolset on CMake command line?
I believe it is "-T llvm" when using the Visual Studio Generators On Sun, May 19, 2019 at 3:33 PM Osman Zakir wrote: > > How do I specify the VS 2019 LLVM toolset when configuring a build with CMake > on the command line? > -- > > 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] Visual Studio platform name ("Win32", "x64") back on CMake GUI window?
Can you submit this to our issue tracker please ( https://gitlab.kitware.com/cmake/cmake/issues ) On Wed, May 22, 2019 at 9:44 AM Niels Dekker wrote: > > Previous versions of CMake GUI (prior to CMake 3.14) always displayed > the name of the selected platform (typically "Win32" or "Win64") with > the current generator, for example: > >"Current Generator: Visual Studio 14 2015 Win64" > > It was very convenient to have the platform name displayed on the main > window of the CMake GUI. > > When a new Visual Studio project is generated "from scratch" by CMake > 3.14, the platform name is no longer displayed with the Current > Generator. As I just tested with CMake 3.14.4, generating for VS2017 > x64. > > Would it be possible to get the VS platform name back onto the CMake GUI > main window? > > > Kind regards, Niels > -- > Niels Dekker > Scientific programmer > LKEB, Leiden University Medical Center > -- > > 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] transitive linkage of OBJECT library targets
This is a known limitation of the current design. Only directly linked object library objects are propagated. For more details on why see: https://gitlab.kitware.com/cmake/cmake/issues/18090 On Wed, May 22, 2019 at 1:48 AM Richard Szabo wrote: > > Hi cmakers > > I'm trying to get the following example working: > ``` > cmake_minimum_required(VERSION 3.14) > project(test_object_lib_nesting) > > set(CMAKE_CXX_STANDARD 14) > > add_library(first_object_lib OBJECT first.cpp) > > add_library(second_object_lib OBJECT second.cpp) > > target_link_libraries(second_object_lib first_object_lib) > > add_executable(test_object_lib_nesting main.cpp) > > target_link_libraries(test_object_lib_nesting second_object_lib) > ``` > > The problem I have that the linker command line will have only the > second.cpp.o for linking the first.cpp.o will not be added as link > object to the exe. Causing missing symbols on exe linkage. > > How to transitively resolve and link "nested" Object library targets ?. > -- > > 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] Building CMake with custom OpenSSL
I don't believe that we test CMake with that configuration of OpenSSL. If it works, I cant promise it will continue to work going forward. On Mon, May 20, 2019 at 4:44 PM A.Dmitrovsky wrote: > > Hi, > > I am building CMake (on x64 linux) with custom OpenSSL and wondering if there > are any CMake requirements on how OpenSSL should be compiled. Specifically, > I'm interested to know if it is valid to link CMake with single-threaded > OpenSSL library (configured with "no-threads" option). > > May be it is documented somewhere? > > Regards, > Anton > -- > > 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
[cmake-developers] [ANNOUNCE] CMake 3.14.4 available for download
We are pleased to announce that CMake 3.14.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.4 since 3.14.3: Alex Turbov (2): FindBoost: Record compiler features for Boost 1.67 and above FindBoost: Fix compiler features for `fiber` and `context` Alexandru Croitor (1): iOS: Fix try_compile FILE_COPY not to fail Brad King (3): target_link_libraries: Fix static library private deps in other dirs Help: Add 3.14.4 release notes CMake 3.14.4 Daniele E. Domenichelli (1): FindSWIG: Support swig4.0 Gregor Jasny (2): Apple: Preserve high resolution mtime for static libraries Apple: Properly lookup XCTest for iOS and tvOS Marc Chevrier (2): FindPython: NumPy: fix erroneous dependencies management FindPython: ensure variable Python_RUNTIME_LIBRARY_DIRS is set correctly -- 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-developers
[CMake] [ANNOUNCE] CMake 3.14.4 available for download
We are pleased to announce that CMake 3.14.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.4 since 3.14.3: Alex Turbov (2): FindBoost: Record compiler features for Boost 1.67 and above FindBoost: Fix compiler features for `fiber` and `context` Alexandru Croitor (1): iOS: Fix try_compile FILE_COPY not to fail Brad King (3): target_link_libraries: Fix static library private deps in other dirs Help: Add 3.14.4 release notes CMake 3.14.4 Daniele E. Domenichelli (1): FindSWIG: Support swig4.0 Gregor Jasny (2): Apple: Preserve high resolution mtime for static libraries Apple: Properly lookup XCTest for iOS and tvOS Marc Chevrier (2): FindPython: NumPy: fix erroneous dependencies management FindPython: ensure variable Python_RUNTIME_LIBRARY_DIRS is set correctly -- 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.13.5 available for download
We are pleased to announce that CMake 3.13.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.13.5 since 3.13.4: Brad King (3): target_link_libraries: Fix static library private deps in other dirs Help: Add 3.13.5 release notes CMake 3.13.5 Nils Gladitz (1): CMake: Fix WiX installer downgrades with versioned binaries -- 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-developers] [ANNOUNCE] CMake 3.13.5 available for download
We are pleased to announce that CMake 3.13.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.13.5 since 3.13.4: Brad King (3): target_link_libraries: Fix static library private deps in other dirs Help: Add 3.13.5 release notes CMake 3.13.5 Nils Gladitz (1): CMake: Fix WiX installer downgrades with versioned binaries -- 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-developers
Re: [CMake] CMake with two C++ compilers
Currently we don't provide the compiler id and version for the CUDA host compiler. If you are interested in having this information can you please create an issue on the cmake gitlab: https://gitlab.kitware.com/cmake/cmake On Fri, May 10, 2019 at 12:09 PM JR Cary wrote: > > Thanks, Chuck. > > I was not clear on my question, which is: When I specify the two compilers, > how > do I get, e.g., CMAKE_CUDA_HOST_COMPILER_ID and > CMAKE_CUDA_HOST_COMPILER_VERSION? > > I need these to determine consistency between the CUDA version and the host > compiler > version, so that I can disable CUDA when these are incmpatible. > > Thanks...John > > On 5/10/19 9:17 AM, Chuck Atkins wrote: > > Hi John, > Two different compilers in the same project for the same language is messy, > but in your case it's directly supproted as a special case for cuda using the > CMAKE_CUDA_HOST_COMPILER CMake variable or the CUDAHOSTCXX environment > variable. > > -- > Chuck Atkins > Staff R Engineer, Scientific Computing > Kitware, Inc. > > > On Wed, May 8, 2019 at 7:27 AM JR Cary wrote: >> >> Is there a standard way to deal with 2 C++ compilers? Getting both >> there versions, etc.? >> >> I need one compiler for compiling ordinary C++ code and a different >> one to use as the host compiler for CUDA. >> >> Thx..John Cary >> -- >> >> 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 -- 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] Support of compile features for Fujitsu C++ Compiler
The goal would be to upstream the compiler changes to cmake so that all users could benefit from the improved compiler detection :) I would look at the FindMPI docs on locating the correct mpi compiler: https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi . It looks like what you will need to specify is MPI__COMPILER_FLAGS On Wed, May 8, 2019 at 10:15 PM Zehner Paul wrote: > > Thank you for your answer. > > This means I have to override > `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This is > not unfeasible, but it may seems tricky to my users. Since detecting compiler > version is not a crucial task, maybe I will keep this file as it and > concentrate on other ones. > > Another question I have is regarding MPI. The `find_package(MPI REQUIRED)` > directive fails with "Could NOT find MPI (missing: MPI_CXX_FOUND)". I have no > clue on how to help the detection of MPI. The compiler I give to CMake is > actually an MPI wrapper that only needs one argument to enable MPI features. > I tried with some exotic-named GCC compilers at my lab (which are MPI > wrappers as well) and it could detect MPI with no problem. Where should I > start? > > Best regards, > > -- > > Paul Zehner, Ph. D. > > Invited Researcher > > Numerical Simulation Research Unit > > Japan Aerospace Exploration Agency > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > > 182-8522, Japan > > Tel. +81-50-3362-7933 > > Fax. +81-422-40-3327 > > zehner.p...@jaxa.jp > > www.jaxa.jp > > > From: Robert Maynard > Sent: Thursday, May 9, 2019 3:12 > To: Zehner Paul > Cc: Kai Wolf; cmake@cmake.org > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler > > I believe the only way is to have your version of > Fujitsu-DetermineCompiler.cmake be installed over the one provided by > CMake. When it comes to known compilers CMake explicitly includes the > version it ships. > > On Tue, May 7, 2019 at 11:01 PM Zehner Paul wrote: > > > > Robert, > > > > Thank you for the advice. > > > > As I want to take account of compiler version, I overrided the > > `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in > > the folder of `CMAKE_MODULE_PATH`. However, the installation > > `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should > > I do? > > > > Best regards, > > > > -- > > > > Paul Zehner, Ph. D. > > > > Invited Researcher > > > > Numerical Simulation Research Unit > > > > Japan Aerospace Exploration Agency > > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > > > > 182-8522, Japan > > > > Tel. +81-50-3362-7933 > > > > Fax. +81-422-40-3327 > > > > zehner.p...@jaxa.jp > > > > www.jaxa.jp > > > > > > From: Robert Maynard > > Sent: Friday, April 26, 2019 23:32 > > To: Zehner Paul > > Cc: Kai Wolf; cmake@cmake.org > > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler > > > > For an initial implementation I would base the work on the PGI > > compiler module ( > > https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake > > ) not the GNU-CXX module. > > This will allow you to add a new compiler with only meta-language > > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of > > having to manually build the feature tables. > > > > On Fri, Apr 26, 2019 at 3:58 AM Zehner Paul wrote: > > > > > > Kai, > > > > > > > > > Thanks for your answer and for your presentation. So, I will try to add > > > support for this Fujitsu compiler. Is there a list of the common compile > > > features that I can base me upon? I plan use `GNU-CXX.cmake` as a source > > > of inspiration. > > > > > > > > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it > > > as a merge request. > > > > > > > > > -- > > > > > > Paul Zehner, Ph. D. > > > > > > Invited Researcher > > > > > > Numerical Simulation Research Unit > > > > > > Japan Aerospace Exploration Agency > > > > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > > > > > > 182-8522, Japan > > > > > > Tel. +81-50-3362-7933 > > > > > > Fax. +81-422-40-3327 > > > > > > zehner.p...@jaxa.jp > > > > > > www.jaxa.jp > > > > > > > > > > > > > > > From: Kai Wolf > > > Sent: Friday, April 26, 2019 16:22 > > > To: Zehner Paul > > > Cc: cmake@cmake.org > > > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler > > > > > > If you want to add support to your specific compiler, you could add or > > > extend another Fujitsu-DetermineCompiler.cmake > > > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You > > > probably also need to adjust > > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on. > > > > > > I gave a talk a few years ago that shortly explains the whole process of > > > CMake initialization and compiler verification which > > > you can find here: > > >
Re: [CMake] Support of compile features for Fujitsu C++ Compiler
I believe the only way is to have your version of
Fujitsu-DetermineCompiler.cmake be installed over the one provided by
CMake. When it comes to known compilers CMake explicitly includes the
version it ships.
On Tue, May 7, 2019 at 11:01 PM Zehner Paul wrote:
>
> Robert,
>
> Thank you for the advice.
>
> As I want to take account of compiler version, I overrided the
> `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the
> folder of `CMAKE_MODULE_PATH`. However, the installation
> `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I
> do?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.p...@jaxa.jp
>
> www.jaxa.jp
>
>
> From: Robert Maynard
> Sent: Friday, April 26, 2019 23:32
> To: Zehner Paul
> Cc: Kai Wolf; cmake@cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> For an initial implementation I would base the work on the PGI
> compiler module (
> https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> ) not the GNU-CXX module.
> This will allow you to add a new compiler with only meta-language
> flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> having to manually build the feature tables.
>
> On Fri, Apr 26, 2019 at 3:58 AM Zehner Paul wrote:
> >
> > Kai,
> >
> >
> > Thanks for your answer and for your presentation. So, I will try to add
> > support for this Fujitsu compiler. Is there a list of the common compile
> > features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of
> > inspiration.
> >
> >
> > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as
> > a merge request.
> >
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.p...@jaxa.jp
> >
> > www.jaxa.jp
> >
> >
> >
> >
> > From: Kai Wolf
> > Sent: Friday, April 26, 2019 16:22
> > To: Zehner Paul
> > Cc: cmake@cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > If you want to add support to your specific compiler, you could add or
> > extend another Fujitsu-DetermineCompiler.cmake
> > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You
> > probably also need to adjust
> > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> >
> > I gave a talk a few years ago that shortly explains the whole process of
> > CMake initialization and compiler verification which
> > you can find here:
> > https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> >
> >
> > Greetings,
> >
> > Kai
> >
> > http://kai-wolf.me
> > http://effective-cmake.com
> >
> > Am 26.04.2019 um 07:35 schrieb Zehner Paul :
> >
> > Hello Cmake community,
> >
> > I would like to use Cmake to build research simulation programs in a
> > Fujitsu supercomputer environment. Unfortunately, it seems that Cmake
> > (version 3.14) does not support any compile feature for the Fujitsu C++
> > compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I
> > add I am pretty new to Cmake. Searching for similar issues, I found only
> > this
> > [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html),
> > which talk about basic support of the compiler.
> >
> > I tested it on a simple project, and the line:
> >
> > ```cmake
> > target_compile_features(test PUBLIC cxx_std_11)
> > ```
> >
> > fails with this message:
> >
> > ```
> > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > target_compile_features no known features for CXX compiler
> >
> > "Fujitsu"
> >
> > version .
> >
> > ```
> >
> > So, it seems that the compiler is detected (without its version), but
> > compile features are not known. To be sure, I ran this simple test to list
> > any supported features:
> >
> > ```cmake
> > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > project(foobar CXX)
> > message("Your C++ compiler supports these C++ features:")
> > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > message("${i}")
> > endforeach()
> > ```
> >
> > and no feature are listed.
> >
> > So, what should I do from now on? Are there some people here using Cmake
> > with Fujitsu who could help me? Should I propose a patch with the different
> > compile features of the compiler? Or should I address it to Fujitsu?
> >
> > Thanks for your help,
> >
> > --
> > Paul Zehner, Ph. D.
> > Invited Researcher
> > Numerical Simulation
Re: [CMake] c++2a
CMake hasn't been updated to be aware that XCode 10 added support for C++20 (via -std=c++2a). I have opened a MR to correct this which you can track at: https://gitlab.kitware.com/cmake/cmake/merge_requests/3294 On Tue, May 7, 2019 at 12:24 PM Angel Campoverde wrote: > > Hi, > > No, It does not work, I told Cmake to use c++ 20, but it still goes back to > c++17. You can see what I get here: > > https://pastebin.com/5ub18cMU > > my CMakeLists.txt is here: > > https://pastebin.com/3bwMKrWB > > do you know what could be the problem? > > Cheers. > > On Tue, May 7, 2019 at 2:33 AM Mateusz Loskot wrote: >> >> On Tue, 7 May 2019 at 01:15, Angel Campoverde >> wrote: >> > >> > I am looking at: >> > >> > https://cmake.org/cmake/help/v3.14/prop_tgt/CXX_STANDARD.html >> > >> > and I see that I can pass 20, for c++20. However I do not have that in my >> > compiler, >> > I only have c++2a and gnu++2a, this means that CMake goes back to c++17 >> >> No, it doesn't mean that. >> >> The valid values documented for CXX_STANDARD are CMake generalisation >> and not what is directly passed via -std= or /std: or whatever option >> your compiler uses. >> >> If you run this cmake command >> cmake -DCMAKE_CXX_STANDARD=20 -DCMAKE_CXX_EXTENSIONS=OFF .. >> and then >> VERBOSE=1 make >> you will clearly see that CMake generated the compiler >> command lines with -std=c++2a >> >> IFF, you are using version of GCC or clang that supports c++2a, obviously >> (i.e. GCC 8/clang 6 or later. I'm not entirely confident about clang) >> >> Best regards, >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> -- >> >> 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 -- 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] Support of compile features for Fujitsu C++ Compiler
For an initial implementation I would base the work on the PGI
compiler module (
https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
) not the GNU-CXX module.
This will allow you to add a new compiler with only meta-language
flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
having to manually build the feature tables.
On Fri, Apr 26, 2019 at 3:58 AM Zehner Paul wrote:
>
> Kai,
>
>
> Thanks for your answer and for your presentation. So, I will try to add
> support for this Fujitsu compiler. Is there a list of the common compile
> features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of
> inspiration.
>
>
> If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a
> merge request.
>
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.p...@jaxa.jp
>
> www.jaxa.jp
>
>
>
>
> From: Kai Wolf
> Sent: Friday, April 26, 2019 16:22
> To: Zehner Paul
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> If you want to add support to your specific compiler, you could add or extend
> another Fujitsu-DetermineCompiler.cmake
> file and append your CMAKE_MODULE_PATH in order to CMake to find it. You
> probably also need to adjust
> *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
>
> I gave a talk a few years ago that shortly explains the whole process of
> CMake initialization and compiler verification which
> you can find here:
> https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
>
>
> Greetings,
>
> Kai
>
> http://kai-wolf.me
> http://effective-cmake.com
>
> Am 26.04.2019 um 07:35 schrieb Zehner Paul :
>
> Hello Cmake community,
>
> I would like to use Cmake to build research simulation programs in a Fujitsu
> supercomputer environment. Unfortunately, it seems that Cmake (version 3.14)
> does not support any compile feature for the Fujitsu C++ compiler (FCCpx,
> version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new
> to Cmake. Searching for similar issues, I found only this
> [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html),
> which talk about basic support of the compiler.
>
> I tested it on a simple project, and the line:
>
> ```cmake
> target_compile_features(test PUBLIC cxx_std_11)
> ```
>
> fails with this message:
>
> ```
> CMake Error at CMakeLists.txt:15 (target_compile_features):
> target_compile_features no known features for CXX compiler
>
> "Fujitsu"
>
> version .
>
> ```
>
> So, it seems that the compiler is detected (without its version), but compile
> features are not known. To be sure, I ran this simple test to list any
> supported features:
>
> ```cmake
> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> project(foobar CXX)
> message("Your C++ compiler supports these C++ features:")
> foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> message("${i}")
> endforeach()
> ```
>
> and no feature are listed.
>
> So, what should I do from now on? Are there some people here using Cmake with
> Fujitsu who could help me? Should I propose a patch with the different
> compile features of the compiler? Or should I address it to Fujitsu?
>
> Thanks for your help,
>
> --
> Paul Zehner, Ph. D.
> Invited Researcher
> Numerical Simulation Research Unit
> Japan Aerospace Exploration Agency
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> 182-8522, Japan
> Tel. +81-50-3362-7933
> Fax. +81-422-40-3327
> zehner.p...@jaxa.jp
> www.jaxa.jp
> --
>
> 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
>
[cmake-developers] [ANNOUNCE] CMake 3.14.3 available for download
We are pleased to announce that CMake 3.14.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.3 since 3.14.2: Ben Boeckel (1): FindOpenGL: look for GLVND libraries with a libglvnd suffix Brad King (4): FindBoost: Add support for MSVC toolset version 14.2 IRSL: Update redist directory for VS 2019 update 1 VS: Provide the default platform name to project code CMake 3.14.3 Christian Pfeiffer (1): FindQt3: Restore missing lib and bin path suffixes Rolf Eike Beer (1): FindBoost: Fix detection with version suffixes on Gentoo -- 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-developers
[CMake] [ANNOUNCE] CMake 3.14.3 available for download
We are pleased to announce that CMake 3.14.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.3 since 3.14.2: Ben Boeckel (1): FindOpenGL: look for GLVND libraries with a libglvnd suffix Brad King (4): FindBoost: Add support for MSVC toolset version 14.2 IRSL: Update redist directory for VS 2019 update 1 VS: Provide the default platform name to project code CMake 3.14.3 Christian Pfeiffer (1): FindQt3: Restore missing lib and bin path suffixes Rolf Eike Beer (1): FindBoost: Fix detection with version suffixes on Gentoo -- 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] CXX and CUDACXX
I don't have any other suggestions. In general I recommend the script approach or using enable_language(CUDA). The enable_language approach should work, so I am curious what other issues you are seeing. On Tue, Apr 16, 2019 at 2:24 PM Dustyn Blasig wrote: > > Thx for the info. > > Since CXX and CUDA are defined together in the project() command, I don't see > a way to inject code to use the CXX compiler if no CUDAHOSTCXX or > CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I tried > moving CUDA out to an enable_language(CUDA) call instead so I could set those > variables between project(foo LANGUAGES CXX) and enable_language(CUDA), but > I'm seeing other issues with that approach. > > Any other suggestions? If not, we'll just wrap our cmake invocation in a > script to help setup the environment properly for now. > > Thx! > > On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard > wrote: >> >> The default implementation is to defer to CUDA for selecting what >> ever host compiler it would like. To make sure that CMake uses the >> same CXX and CUDACXX compiler you will need to explicitly state that >> either through the CUDAHOSTCXX env variable ( >> https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with >> CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. -- 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] CXX and CUDACXX
The default implementation is to defer to CUDA for selecting what ever host compiler it would like. To make sure that CMake uses the same CXX and CUDACXX compiler you will need to explicitly state that either through the CUDAHOSTCXX env variable ( https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. -- 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.14.2 available for download
We are pleased to announce that CMake 3.14.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.2 since 3.14.1: Brad King (9): MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset ARMCC: Do not identify ARMClang as ARMCC IRSL: Fix discovery of VS 2019 v142 toolset redistributables Tests: Clarify hand-written cases in RunCMake.ParseImplicitIncludeInfo Tests: Teach RunCMake.ParseImplicitIncludeInfo to match output by regex Fix implicit include directory extraction for adaptive relative paths Xcode: Factor out duplicate source group code into lambda Xcode: Avoid mutating App Bundle targets during generation CMake 3.14.2 Julien Jomier (1): cmake-gui: Fix icon overlay on windows Regina Pfeifer (1): Modules/CTest: Fix SubmitURL mistersandman (1): cmake-gui: Fix theme on Windows with Qt >= 5.10 -- 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-developers] [ANNOUNCE] CMake 3.14.2 available for download
We are pleased to announce that CMake 3.14.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.2 since 3.14.1: Brad King (9): MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset ARMCC: Do not identify ARMClang as ARMCC IRSL: Fix discovery of VS 2019 v142 toolset redistributables Tests: Clarify hand-written cases in RunCMake.ParseImplicitIncludeInfo Tests: Teach RunCMake.ParseImplicitIncludeInfo to match output by regex Fix implicit include directory extraction for adaptive relative paths Xcode: Factor out duplicate source group code into lambda Xcode: Avoid mutating App Bundle targets during generation CMake 3.14.2 Julien Jomier (1): cmake-gui: Fix icon overlay on windows Regina Pfeifer (1): Modules/CTest: Fix SubmitURL mistersandman (1): cmake-gui: Fix theme on Windows with Qt >= 5.10 -- 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-developers
Re: [CMake] Does enable_language(CUDA) still have the problem with reconfiguring?
Yes, we are dependent on the CUDA extensions for ms-build working correctly. On Mon, Apr 1, 2019 at 5:02 PM Mojca Miklavec wrote: > > On Mon, 1 Apr 2019 at 22:11, Robert Maynard via CMake wrote: > > > > For MSBuild we rely on the CUDA extensions written by nvidia which do > > proper dependency tracking. > > Except when they don't. It drove me nearly crazy that any given > trivial change had to be followed by a complete rebuild of the > project. > > But I see that someone commented an hour ago: > > https://stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files > saying that the fix has finally arrived (in March). > > Mojca -- 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] Does enable_language(CUDA) still have the problem with reconfiguring?
It doesn't have this behavior. For Makefile and Ninja generators we get the proper header dependencies at compile time just like we do for C or C++. For MSBuild we rely on the CUDA extensions written by nvidia which do proper dependency tracking. On Sat, Mar 30, 2019 at 4:12 PM JR Cary wrote: > > Re the thread below, > > Does the newer, enable_languagedo a better job of not having the > repeated reconfigurations and full project rebuilds as described at > > https://cmake.org/pipermail/cmake/2011-January/042173.html > > and many times after? > > John > > > > On 3/30/19 6:45 AM, cmake-requ...@cmake.org wrote: > > - > > Message: 4 > > Date: Sat, 30 Mar 2019 12:45:07 + > > From: Luis Caro Campos > > > > I believe the closest equivalent to settinga CUDA_TOOLKIT_ROOT_DIR when > > using enable_language(CUDA) is to set either the environment variable > > CUDACXX or the CMake cache entry CMAKE_CUDA_COMPILER to point to the > > location of the nvcc compiler. > > > > However I think there are still some "features" of FindCUDA that > > enable_language don't support, e.g. variables and/or import targets with > > locations, see https://gitlab.kitware.com/cmake/cmake/issues/17816 > > > > Kind regards, > > Luis > > > > On Fri, Mar 29, 2019 at 4:57 PM Dustyn Blasig wrote: > > > >> "we should not try to combine enable_language(CUDA) with > >> find_package(CUDA). They do not work together, either use one or another." > >> > >> Absolutely, my goal is to move to the new built-in language support. I'm > >> having trouble doing that because I can't find any documentation on it. For > >> instance, what is the new equivalent CUDA_TOOLKIT_ROOT_DIR? Without > >> find_package(CUDA), I don't see anything set that have the equivalent. > >> Also, in some cases the CUDA include directory is added to targets, and in > >> other cases it isn't, even if the target depends on source with .cu. What > >> is the documented behavior for this? > >> > >> I'm sure there has to be a page somewhere on this, but going to page 4 on > >> Google search didn't uncover anything, and the first 2 pages all point to > >> various versions of FindCUDA : ) > >> > >> On Fri, Mar 29, 2019 at 11:28 AM Dmitry Mikushin < > >> dmi...@parallel-computing.pro> wrote: > >> > >>> Hi, > >>> > >>> That was my confusion as well: to my understanding, we should not try to > >>> combine enable_language(CUDA) with find_package(CUDA). They do not work > >>> together, either use one or another. > >>> > >>> Kind regards, > >>> - Dmitry. > >>> > >>> ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : > >>> > Hi All, > > I can't find any documentation on the new-ish "native" CUDA support. I > need to know all the variables that we can use, and (for instance) > whether > checking the CUDA version is now supported. When searching online, I'm > always directed to the old FindCUDA pages which don't seem to match what > is > available with the native language support. > > Currently, I'm "hacking" my way through things by using both flows. I > add CUDA as a language, use the found CUDA compiler to construct a > CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old > environment variables set up. > > Cheers! > > > -- > > 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
[cmake-developers] [ANNOUNCE] CMake 3.14.1 available for download
We are pleased to announce that CMake 3.14.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.1 since 3.14.0: Brad King (11): VS: Fix x64 host recognition by x86 cmake process find_program: Restore leading double slash on Windows network path Eclipse: Fix extra generator to not crash on interface libraries ARMCC: Fix identification of ARM compiler when it defines GNU macros Help: Clarify policy CMP0082 documentation Restore support for include_directories() in toolchain files CUDA: Tolerate square brackets in PROMPT environment variable cmake: Fix '-E copy foo .' to avoid clobbering file FindFontconfig: Convert module variables to camel case ParseImplicitIncludeInfo: Canonicalize implicit include dirs CMake 3.14.1 Clément Rezvoy (1): CPackIFW: Add missing cpack_ifw_configure_component_group option processing Marc Chevrier (1): FindPython*: ensure correct architecture is selected. Sebastian Holtermann (1): Autogen: Do not treat hard-coded -I/usr/include exclusion as implicit include Sylvain Joubert (1): ctest_coverage: fix out-of-bounds index in Jacoco parser -- 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-developers
[CMake] [ANNOUNCE] CMake 3.14.1 available for download
We are pleased to announce that CMake 3.14.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.1 since 3.14.0: Brad King (11): VS: Fix x64 host recognition by x86 cmake process find_program: Restore leading double slash on Windows network path Eclipse: Fix extra generator to not crash on interface libraries ARMCC: Fix identification of ARM compiler when it defines GNU macros Help: Clarify policy CMP0082 documentation Restore support for include_directories() in toolchain files CUDA: Tolerate square brackets in PROMPT environment variable cmake: Fix '-E copy foo .' to avoid clobbering file FindFontconfig: Convert module variables to camel case ParseImplicitIncludeInfo: Canonicalize implicit include dirs CMake 3.14.1 Clément Rezvoy (1): CPackIFW: Add missing cpack_ifw_configure_component_group option processing Marc Chevrier (1): FindPython*: ensure correct architecture is selected. Sebastian Holtermann (1): Autogen: Do not treat hard-coded -I/usr/include exclusion as implicit include Sylvain Joubert (1): ctest_coverage: fix out-of-bounds index in Jacoco parser -- 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] Strange issue with 3.14.0 and copying files
Just as a follow-up for the general community, this is a bug and can be tracked at: https://gitlab.kitware.com/cmake/cmake/issues/19075 On Wed, Mar 20, 2019 at 2:46 PM Ron Olson wrote: > > Hi all- > > As a way of introduction, I’m Ron, and I maintain Apple’s Swift > programming language package for Fedora. I’ve been tracking down a > build failure and I came across a weird issue using 3.14.0 that > doesn’t seem to be a problem on 3.12.1. If you copy a file to the same > location, it overwrites it with a zero byte file: > > [rolson@testn temp]$ cmake --version > cmake version 3.14.0 > > CMake suite maintained and supported by Kitware (kitware.com/cmake). > > [rolson@testn temp]$ echo "hello world" > foo.txt > > [rolson@testn temp]$ ls -lah > total 8.0K > drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . > drwx--. 9 rolson rolson 4.0K Mar 20 16:22 .. > -rw-rw-r--. 1 rolson rolson 12 Mar 20 16:39 foo.txt > > [rolson@testn temp]$ cmake -E copy foo.txt . > > [rolson@testn temp]$ ls -lah > total 4.0K > drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . > drwx--. 9 rolson rolson 4.0K Mar 20 16:22 .. > -rw-rw-r--. 1 rolson rolson0 Mar 20 16:39 foo.txt > > I haven’t been able to find any documentation about whether this is > expected behavior or not; under 3.12.1 the result would be foo.txt would > remain untouched. > > If it’s a bug, I’ll file a report, but wanted to make sure it is > before I do so. > > Ron > > > > > > > > -- > > 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] CMake Project Generation Speedup
A round of performance improvements to generate time was done as part of CMake 3.11 and that significantly helped. What would be helpful is a performance analysis run of CMake itself to determine if the issue is that we are IO bound ( and need to do multi-threaded writes ) or compute bound. While this information will be project dependent, it would be great to start getting samples from the community. On Wed, Mar 20, 2019 at 1:53 PM J. Caleb Wherry wrote: > > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native C++, > Managed C++, C#, Java, CUDA, etc) and the majority of the time for the > configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the > project files and filters for each C++ project (the majority of our projects) > for VS generators (what we use). I'm just looking to see if there is anything > to look at or potentially speedup up the generate step besides "get a faster > drive". > > Thanks! > -Caleb > > On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: >> >> Hi all, >> >> We are still in the process of switching our large Make-based build to >> CMake. One of the issues we're running into is the time it takes to reparse >> and regenerate the CMake project (whether ninja, VS, or make) after touching >> any CMake file. To give you an idea, we have about 1000 targets and that >> takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or do >> a better job regenerating only what needs regenerating? Is there anything we >> can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that has >> a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one >> of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > > -- > J. Caleb Wherry > Scientific Software Engineer > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwhe...@gmail.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 -- 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.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/
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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
"CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all
targets.
File-Based API
--
* A file-based api for
[cmake-developers] [ANNOUNCE] 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/
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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
"CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all
targets.
File-Based API
--
* A file-based api for
[cmake-developers] [ANNOUNCE] CMake 3.14.0-rc4 is ready for testing
I am proud to announce the fourth CMake 3.14 release candidate.
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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
[CMake] [ANNOUNCE] CMake 3.14.0-rc4 is ready for testing
I am proud to announce the fourth CMake 3.14 release candidate.
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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
[CMake] [ANNOUNCE] CMake 3.14.0-rc3 is ready for testing
I am proud to announce the third CMake 3.14 release candidate.
https://cmake.org/download/
The first two 3.14.0 release candidates included the FindOcatave
module. This has been removed in rc3 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
[cmake-developers] [ANNOUNCE] CMake 3.14.0-rc3 is ready for testing
I am proud to announce the third CMake 3.14 release candidate.
https://cmake.org/download/
The first two 3.14.0 release candidates included the FindOcatave
module. This has been removed in rc3 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
Re: [CMake] CUDA language support with host compiler flags
Currently to get proper propagation of architecture flags such as
-arch=sm_50, -compute=compute_X you need to place these into the
CMAKE_CUDA_FLAGS. This is a known issue, as flags specified by
`target_compile_options` are not propagate to the device linking step,
which needs the correct architecture flags.
On Thu, Feb 28, 2019 at 8:13 AM Máté Ferenc Nagy-Egri
wrote:
>
> Hi Robert!
>
>
>
> Thank you for the help. I don’t know if I could’ve find that solution myself.
> I guess selecting CUDA as the COMPILE_LANGUAGE I can controll .cu compiler
> options to select architecture and what not.
>
>
>
> Anyhow, if someone needed the minimal template, here it is:
>
>
>
> https://gist.github.com/MathiasMagnus/0edacac888a758fe233cb69f3e291d62
>
>
>
> Cheers,
>
> Máté
>
>
>
> Feladó: Robert Maynard
> Elküldve: 2019. február 27., szerda 15:00
> Címzett: Nagy-Egri MĂĄtĂŠ Ferenc
> Másolatot kap: CMake MailingList
> Tárgy: Re: [CMake] CUDA language support with host compiler flags
>
>
>
> You need to guard the flags with `$` the
>
> evaluation on a given compiler id is done for all sources of a target,
>
> and not on each target source file.
>
>
>
> So you will need something like:
>
>
>
> set(cxx_flags "$<$,$>:-Wall
>
> -Wextra -pedantic>
>
>$<$:/W4")
>
> target_compile_options(${PROJECT_NAME} PRIVATE
>
> $<$:${cxx_flags}>)
>
>
>
> On Fri, Feb 22, 2019 at 4:11 AM Máté Ferenc Nagy-Egri via CMake
>
> wrote:
>
> >
>
> > Hi All!
>
> >
>
> > I am trying to compile CUDA code with controlling both host and device
> > compiler flags.
>
> >
>
> > Currently my CMakeLists.txt looks like:
>
> >
>
> > ```
>
> > cmake_minimum_required(VERSION 3.8) # CUDA language support
>
> >
>
> > project(CUDA_test LANGUAGES CXX CUDA)
>
> >
>
> > if (MSVC)
>
> > string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>
> > endif (MSVC)
>
> >
>
> > set(Hdrs)
>
> >
>
> > set(Srcs Main.cu)
>
> >
>
> > add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
>
> >
>
> > target_include_directories(${PROJECT_NAME} PRIVATE
> > ${CMAKE_CURRENT_SOURCE_DIR})
>
> >
>
> > target_compile_options(${PROJECT_NAME} PRIVATE
> > $<$,$>:-Wall -Wextra
> > -pedantic>
>
> >
> > $<$:/W4>)
>
> >
>
> > set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION
> > ON
>
> > CUDA_STANDARD 14
>
> > CUDA_STANDARD_REQUIRED ON
>
> > CUDA_EXTENSIONS OFF
>
> > CXX_STANDARD 14
>
> > CXX_STANDARD_REQUIRED ON
>
> > CXX_EXTENSIONS OFF)
>
> >
>
> > source_group ("Headers" FILES ${Hdrs})
>
> > source_group ("Sources" FILES ${Srcs})
>
> > ```
>
> >
>
> > However, when I compile the code I get the following error:
>
> >
>
> > [1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
>
> > FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
>
> > /usr/bin/nvcc
> > -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g
> > -Wall -Wextra -pedantic -std=c++14 -x cu -dc
> > /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o
> > CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc
> > -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g
> > -Wall -Wextra -pedantic -std=c++14 -x cu -M
> > /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT
> > CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
>
> > nvcc fatal : Unknown option 'Wall'
>
> > ninja: build stopped: subcommand failed.
>
> >
>
> > CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well,
> > even though it is neither GNU nor Clang, but CUDA. How can I specify
> > warning and similar flags separatly for the host and device compilers?
>
> > --
>
> >
>
> > 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
Re: [CMake] Getting the path to object files?
You can file an enhancement request that the $ generator expression to be relaxed to include STATIC, SHARED, and MODULE libraries. My suggestion is that a dummy source file to workaround the Xcode limitation on targets, is not as hacky as reverse engineering the object file locations. On Wed, Feb 27, 2019 at 9:06 AM Paul Smith wrote: > > On Wed, 2019-02-27 at 08:39 -0500, Robert Maynard wrote: > > CMake only provides an official way to get the location of the object > > files for OBJECT targets ( $ ). For other > > target types the location is an implementation detail. > > Yes, but sometimes (as in my case) I need to know it :). I need to > examine the object files as part of my link processing. > > Exactly _because_ it's an implementation detail, it would be nice if > there were some way to retrieve it from CMake. I can file an > enhancement request if that seems appropriate. > > I could use an OBJECT target if it weren't for the Xcode restriction > that a STATIC or SHARED library must have at least one source file and > can't consist solely of an OBJECT library. > > I'm hopeful we can throw away our MacOS builds entirely but until that > happens... > > > Thanks for the reply Robert! > -- 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] transitive interface dependency problem
If `interfaceDep` is an actual interface target, consuming libraries of libA inside the project ( example ) should resolve it as an interface target and not drop it on the lnik line. If you have a small self contained example that would help track down this issue. On Thu, Feb 21, 2019 at 5:49 AM Starka Tomáš wrote: > > Hi all, > following my previous post 'link only with targets feature' I have > found yet another unpleasant consequence of not being able to tell > cmake that it is the target name in the parameters of > target_link_libraries (without the use of :: notation, that is > optional and inconsistent). When I have library A which have an > interface dependency interfaceDep and when using the export sets to > automaticaly generate the configs while simultaneously internaly > building an example app that is using lib A. I have encountered the > following problem: > In the cmake of lib A I do NOT search for the interfaceDep since > there is no reason to, because the lib A compiles and links without > it. But to relate that dependency to autogenerated config I need to > state target_link_libraries(A INTERFACE interfaceDep), and then, for > downstreamers, I need to handle the finding of it by hand in the > config before the *Targets.cmake gets included (that's kind of ok and > could be automated by cmake if we had consistent target naming > syntax). Back to the build tree of the project for lib A. In the later > subdirectories where I build an example app the > target_link_libraries(example A) makes it wants interfaceDep.lib > (which is non-existent since its only interface lib) eventhough there > is correct interfaceDep target found prior to that in the app cmake. > The thing is that the interfaceDep is resolved not in the application > cmake but in the lib A cmake where there is no target of that name and > the target_link_libraries doesn't know that it is supposed to be a > target. I hope I didn't lost you yet. > I have come with two solutions. One is to not use INTERFACE > dependencies ever and injecting them by hand in the config scripts for > downstreamers - which seems more dirty and confusing and then in the > same buildtree doing the same for all the apps/libs that uses lib A. > The other solution is to create a dummy target - > add_library(interfaceDep INTERFACE IMPORTED) in the lib A cmake just > before you call target_link_libraries(A INTERFACE interfaceDep), which > is less dirty but dirty nontheless. > Is there any other idiomatic approach? And NOTE that "use > interfaceDep::interfaceDep" named target is not possible since it > could be target created by 3rd party and you can't alias an IMPORTED > target ;) (e.g. glm). It would realy help if there would be a 'link > only with targets feature' in the cmake with all the consequences. > If you see it fit, you can also forward this to the developer only > mailing-list. But I've started a new thread since it opens (and > possibly resolves) a new isssue. > > Hope posing these points will help > forry > > -- > > 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] CUDA language support with host compiler flags
You need to guard the flags with `$` the
evaluation on a given compiler id is done for all sources of a target,
and not on each target source file.
So you will need something like:
set(cxx_flags "$<$,$>:-Wall
-Wextra -pedantic>
$<$:/W4")
target_compile_options(${PROJECT_NAME} PRIVATE
$<$:${cxx_flags}>)
On Fri, Feb 22, 2019 at 4:11 AM Máté Ferenc Nagy-Egri via CMake
wrote:
>
> Hi All!
>
> I am trying to compile CUDA code with controlling both host and device
> compiler flags.
>
> Currently my CMakeLists.txt looks like:
>
> ```
> cmake_minimum_required(VERSION 3.8) # CUDA language support
>
> project(CUDA_test LANGUAGES CXX CUDA)
>
> if (MSVC)
> string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif (MSVC)
>
> set(Hdrs)
>
> set(Srcs Main.cu)
>
> add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
>
> target_include_directories(${PROJECT_NAME} PRIVATE
> ${CMAKE_CURRENT_SOURCE_DIR})
>
> target_compile_options(${PROJECT_NAME} PRIVATE
> $<$,$>:-Wall -Wextra
> -pedantic>
>$<$:/W4>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION ON
> CUDA_STANDARD 14
> CUDA_STANDARD_REQUIRED ON
> CUDA_EXTENSIONS OFF
> CXX_STANDARD 14
> CXX_STANDARD_REQUIRED ON
> CXX_EXTENSIONS OFF)
>
> source_group ("Headers" FILES ${Hdrs})
> source_group ("Sources" FILES ${Srcs})
> ```
>
> However, when I compile the code I get the following error:
>
> [1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
> FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
> /usr/bin/nvcc
> -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g -Wall
> -Wextra -pedantic -std=c++14 -x cu -dc
> /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o
> CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc
> -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g -Wall
> -Wextra -pedantic -std=c++14 -x cu -M
> /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT
> CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
> nvcc fatal : Unknown option 'Wall'
> ninja: build stopped: subcommand failed.
>
> CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well,
> even though it is neither GNU nor Clang, but CUDA. How can I specify warning
> and similar flags separatly for the host and device compilers?
> --
>
> 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] Getting the path to object files?
CMake only provides an official way to get the location of the object
files for OBJECT targets ( $ ). For other
target types the location is an implementation detail.
On Sat, Feb 23, 2019 at 3:24 PM Paul Smith wrote:
>
> Hi all. I'm using CMake 3.13.4 across Linux, MacOS, and Windows, with
> various generators.
>
> I need to write a script (this only runs on Linux actually) that will
> do some processing on all the object files in a shared library and
> generate a linker version file. I'm trying to write a custom command
> using PRE_LINK that will invoke that script and pass along enough
> information to find all those object files so it can generate the
> version file, and I can't come up with it.
>
> For example, using a Makefile generator for a file "libsrc.cpp" built
> for a library "solib" in a directory "LibDir" on Linux my object file
> paths look like:
>
> LibDir/CMakeFiles/solib.dir/libsrc.cpp.o
>
> I can use something like this:
>
> get_target_property(srcs solib SOURCES)
>
> add_custom_command(TARGET solib PRE_LINK
> COMMAND foo ${srcs}
> VERBATIM)
>
> (for some reason if I try to use a generator expression like
> $ etc. it's always passed as a single quoted
> argument and I can't figure out how break it up, but if I use
> get_target_property() then it works correctly).
>
> However this only gives me the source file names, not the object file
> names, and no directory information to search. My problem is I'm
> actually compiling these same source files multiple times in different
> ways for different libraries, so I can't just search for "libsrc.cpp.o"
> I need to get this particular .o.
>
> So then I added $ which looked promising,
> but it only gives me the path to the source directory; i.e. above it
> gives me LibDir.
>
> I tried lots of different likely-looking properties, but I can't find
> any property which will tell me the path I'm looking for.
>
> Can I get CMake to tell me the path where the object files being
> created will be put for a given target? Or do I just need to hard-code
> it based on my observations of how cmake generators actually create the
> output?
>
> --
>
> 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] [SPAM] Re: [SPAM] Re: resource installation
I believe the problem is related to execute_process CODE not being
quoted. So the following works for me:
install(CODE
"
execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err
)
"
)
The other option you have is using CMake's 3.X new bracket strings (
https://cmake.org/cmake/help/v3.4/manual/cmake-language.7.html#bracket-argument
) which stop
any CMake configure expansion. This makes it significantly easier to
pass down code strings, but you do have to remember to have a preamble
that sends down any
variables expanded that you need. So your example would look like this:
#First send down the variables you need expanded at CMake configure time
install(CODE
"
set(CMAKE_CURRENT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(WIN_PLATFORM ${WIN_PLATFORM})
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE})
"
)
#now send down the unexpanded commands to run
install(CODE [==[message("running
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}")]==])
install(CODE
[==[
execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err
)
]==]
)
On Tue, Feb 12, 2019 at 2:12 PM Rob Boehne wrote:
>
> The same behavior is also present in version 3.14.0-rc1.
>
> On 2/12/19, 11:54 AM, "CMake on behalf of Rob Boehne"
> wrote:
>
> Hmmm, I think I've found a bug. Here is what I have in my top-level
> CMakeLists.txt file:
>
>
> if(WIN32)
> #
> # run the script to install the resources
> #
> set(RI_RESULT " ")
> set(RI_OUTPUT " ")
> set(RI_ERROR " ")
>
> install(CODE "message(\"running
> ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
> ${CMAKE_BUILD_TYPE}\")")
>
> install(CODE execute_process(COMMAND
> ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
> ${CMAKE_BUILD_TYPE}
> RESULT_VARIABLE RI_RESULT
> OUTPUT_VARIABLE RI_OUTPUT
> ERROR_VARIABLE RI_ERROR
> OUTPUT_FILE ResInst.out
> ERROR_FILE ResInst.err )
>)
>
> install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\"
> output: \\\"${RI_OUTPUT}\\\" error: \\\"${RI_ERROR}\\\" \")")
>
> endif()
>
>
> (As you can see I haven't figured out quoting yet)
> This is what comes out of the above code:
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
> CMAKE_INSTALL_COMPONENT)
> message("running
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
> Release")
> endif()
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
> CMAKE_INSTALL_COMPONENT)
> execute_process(COMMAND
> "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
> Release"
> WORKING_DIRECTORY
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
> RESULT_VARIABLE RI_RESULT
> OUTPUT_VARIABLE RI_OUTPUT
> ERROR_VARIABLE RI_ERROR
> OUTPUT_FILE ResInst.out
> ERROR_FILE ResInst.err ")
> endif()
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
> CMAKE_INSTALL_COMPONENT)
> message("ResourceInstall results output: error: ")
> endif()
>
>
> From cmake 3.12.2 on Win64. The issue is the closing quote inside
> "execute_process" which appears to have been magically added by cmake.
> When I run the cmake_install.cmake as is it fails on that line:
>
>
> CMake Error at cmake_install.cmake:87:
> Parse error. Function missing ending ")". Instead found unterminated
> string with text ")
>
> ".
>
> If I remove that stray double quote, it runs, doing all the subdir
> install tasks, but still doesn't run the ResourceInstall.bat file.
> And it generates the error:
>
> 1> -- Installing:
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
> 1>C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
> error MSB3073: The command "setlocal
> 1>C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
> error MSB3073: "C:\Program Files\CMake\bin\cmake.exe"
> -DBUILD_TYPE=RelWithDebInfo -P cmake_install.cmake
> 1>C:\Program Files
>
[cmake-developers] [ANNOUNCE] CMake 3.14.0-rc2 is ready for testing
I am proud to announce the second CMake 3.14 release candidate.
https://cmake.org/download/
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 2" 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* The "Visual Studio 16 2019" generator was added. This is
experimental and based on "Visual Studio 2019 Preview 2" 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
"CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all
targets.
File-Based API
--
* A file-based api for clients to get
[CMake] [ANNOUNCE] CMake 3.14.0-rc2 is ready for testing
I am proud to announce the second CMake 3.14 release candidate.
https://cmake.org/download/
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 2" 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* The "Visual Studio 16 2019" generator was added. This is
experimental and based on "Visual Studio 2019 Preview 2" 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:
* Now supports Object Libraries.
* Now warns on unsupported project types such as shared libraries.
* Now generates a top-level ".top.gpj" for each
directory calling the "project()" command. The top-level project
file "default.gpj" is no longer created.
* Now honors target renaming and destination output control
properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
This also fixes support for installation rules generated by
"install()".
* Now honors source file properties "INCLUDE_DIRECTORIES",
"COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".
* Now supports Dynamic Download Integrity Applications which did
not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
target link flag of "-dynamic".
* The contents of project files now sorts sources groups and files
by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
"ON" to generate a single project file for the target instead of a
project file for each source group. Set the
"CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all
targets.
File-Based API
--
* A file-based api for clients to get
Re: [CMake] Redundant linking when modifying shared libraries
I agree that we should document this property better. I recommend looking at the CMake wiki ( https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking maybe adding a new recipe for `optimizing redundant linking`. On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel wrote: > > On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard > wrote: > > By default CMake wants to get a correct build 100% of the time. There > > is nothing to stop people from having functions defined in a .cxx file > > with no corresponding header, and using manual forward deceleration is > > used in a consuming library/executable. By setting > > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link > > time error ( renaming the function in the .cxx ) to a run time error. > > First of all, thanks for the answer - it's good to understand the > rationale and to know that in our use case we can safely use this > setting. > > On the question of whether to set this as the default, I understand > your position and I personally disagree - but do not wish to start a > debate. However I will say that this simple change has, in a common > case, reduced my build time from 5 minutes to 15 seconds. At the very > least could you consider steps to make this setting more known and > accessible? (No one on Stack Overflow knew about it, and I think > that's saying something.) Perhaps put it in a FAQ, and/or more > prominently in the documentation. > > Kind regards, > > itay > -- > > 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] Redundant linking when modifying shared libraries
> I wonder why this isn't the default behavior By default CMake wants to get a correct build 100% of the time. There is nothing to stop people from having functions defined in a .cxx file with no corresponding header, and using manual forward deceleration is used in a consuming library/executable. By setting `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link time error ( renaming the function in the .cxx ) to a run time error. On Thu, Feb 14, 2019 at 12:11 PM Itay Chamiel wrote: > > On Thu, Feb 14, 2019 at 12:39 PM Craig Scott wrote: > > I think you might be looking for the LINK_DEPENDS_NO_SHARED target property > > (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable). > > After my previous response I experimented a little more, and I got it > to work. My mistake was that I needed to add the configuration line to > the executable target, not the lib. So in my example, add the > following line to the Demo/CMakeLists.txt file: > > set_target_properties(helloDemo PROPERTIES LINK_DEPENDS_NO_SHARED true) > > ..and it works like a charm. I wonder why this isn't the default > behavior; can you think of any scenario where this would produce > invalid results? > > Thanks for your help! > > itay > -- > > 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] [CMAKE] Disable testing when building using bootstrap
You can pass CMake arguments to the bootstrap by doing: ./bootstrap -- -DBUILD_TESTING=OFF On Mon, Feb 11, 2019 at 12:03 PM Jon Haitz Legarreta Gorroño wrote: > > Hi, > > I'm trying to build CMake from sources using the `bootstrap` script. > > Please, correct me if I'm wrong, but it looks like CMake is being > built with `BUILD_TESTING=ON` by default. > > I'd like to disable testing (and any other non-essential option), but > AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have > not found a way to set it to `OFF`. > > Is this possible / does this make sense at all? Can anyone please > provide me with the pointers to do so? > > Thank you, > JON HAITZ > -- > > 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
[cmake-developers] [ANNOUNCE] CMake 3.14.0-rc1 is ready for testing
I am proud to announce the first CMake 3.14 release candidate.
https://cmake.org/download/
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 2" 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.
* 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* The "Visual Studio 16 2019" generator was added. This is
experimental and based on "Visual Studio 2019 Preview 2" 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.
File-Based API
--
* 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.
Platforms
-
* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
simple toolchain files.
Command-Line
* 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.
* The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to
explicitly specify source and build directories.
Commands
* The "file()" command learned a new sub-command, "READ_SYMLINK",
which can be used to determine the path that a symlink points to.
* The "file()" command gained a "SIZE" mode to get the size of a
file on disk.
* The "find_package()" command learned to optionally resolve
symbolic links in the paths to package configuration files. See the
"CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable.
* The "get_filename_component()" command gained new "LAST_EXT" and
"NAME_WLE" variants to work with the extension after the last "." in
[CMake] [ANNOUNCE] CMake 3.14.0-rc1 is ready for testing
I am proud to announce the first CMake 3.14 release candidate.
https://cmake.org/download/
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 2" 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.
* 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.
CMake 3.14 Release Notes
Changes made since CMake 3.13 include the following.
New Features
Generators
--
* The "Visual Studio 16 2019" generator was added. This is
experimental and based on "Visual Studio 2019 Preview 2" 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.
File-Based API
--
* 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.
Platforms
-
* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
simple toolchain files.
Command-Line
* 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.
* The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to
explicitly specify source and build directories.
Commands
* The "file()" command learned a new sub-command, "READ_SYMLINK",
which can be used to determine the path that a symlink points to.
* The "file()" command gained a "SIZE" mode to get the size of a
file on disk.
* The "find_package()" command learned to optionally resolve
symbolic links in the paths to package configuration files. See the
"CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable.
* The "get_filename_component()" command gained new "LAST_EXT" and
"NAME_WLE" variants to work with the extension after the last "." in
Re: [CMake] cmake with vscode
CMAKE_FIND_ROOT_PATH isn't meant to be used like that, you should use
CMAKE_PREFIX_PATH I expect.
ROOT_PATH represents the root of a new file-system/OS basically and is
meant for cross-compilation. While what you want is extra directories
to start searching from which is what CMAKE_PREFIX_PATH is designed
for.
On Tue, Jan 22, 2019 at 8:51 AM Stéphane Ancelot
wrote:
>
> Hi,
>
> I have got some problems finding packages under windows platform.
>
> I made a toolchain for VSCode and cmake 3.13 , but I don't understand why it
> fails to find almost all of my packages dependencies
>
> It is not able to find packages in the CMAKE_FIND_ROOT_PATH itself.
>
> If I try setting xx_LIBRARY and xx_INCLUDE_DIRS, if finds libs, but this
> does not sound the right Way .
>
>
> Here is my toolchain :
>
> # the name of the target operating system
> SET(CMAKE_SYSTEM_NAME Windows)
>
> message(STATUS "bin dir ${CMAKE_BINARY_DIR}")
>
> # here is the target environment located
> SET(CMAKE_FIND_ROOT_PATH
>
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\xerces\\xerces-c-3.1.1-bin
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\JPEGLIB\\jpegsrc-9c
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\zlib-1.2.3-lib
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\libpng-1.2.37-lib
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\freetype-dev_2.4.2-1
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\iconv-1.9.2.1
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\Python26
> E:\\Qt\\5.9.5
> )
>
> # cmake 3.13
> set(FREETYPE_LIBRARY E:\\freetype-windows-binaries-master\\lib)
> set(FREETYPE_INCLUDE_DIRS E:\\freetype-windows-binaries-master\\include)
>
> set(FTGL_LIBRARY ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\lib)
> set(FTGL_INCLUDE_DIRS ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\include)
>
>
>
> --
>
> 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] [SPAM] Re: resource installation
If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
execute_process call you should be able to dump the information using
'message' and see if the execute_process is running.
On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne wrote:
>
> I’m still not getting this script executed. I can copy the “message” output
> and run it – and it does what I want, and I see it in cmake_install.cmake –
> the message() and execute_process() calls are inside of identical
> conditionals, but there’s no indication that it is executing, or that there
> was any sort of problem.
>
> How do I get it to actually execute?
>
>
>
> In cmake_install.cmake:
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
> CMAKE_INSTALL_COMPONENT)
>
> message("running
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
> Release")
>
> endif()
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
> CMAKE_INSTALL_COMPONENT)
>
> execute_process(COMMAND
> "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
> Release")
>
> endif()
>
>
>
>
>
> From: CMake on behalf of Rob Boehne
>
> Date: Thursday, January 24, 2019 at 9:49 AM
> To: "cmake@cmake.org"
> Subject: [SPAM] Re: [CMake] resource installation
>
>
>
> Maybe because I misspelled it? Yes. Because I misspelled the script name.
>
>
>
> From: CMake on behalf of Rob Boehne
>
> Date: Thursday, January 24, 2019 at 9:40 AM
> To: "cmake@cmake.org"
> Subject: [SPAM] [CMake] resource installation
>
>
>
> All,
>
>
>
> I’m attempting to install resource files (Fonts, etc.) into my product. To
> that end, I have added this chunk of code to run a batch file that will copy
> resources into the tree:
>
>
>
> if(WIN32)
>
> #
>
> # run the script to install the resources
>
> #
>
> install(CODE "message(\"running
> ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
> ${CMAKE_BUILD_TYPE}\")")
>
> install(CODE "execute_process(COMMAND
> \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
> ${CMAKE_BUILD_TYPE}\")")
>
> endif()
>
>
>
> I see the output of the first line when I run the INSTALL target in VS 2013,
> but it seems as though the script isn’t run.
>
> 1> -- Install configuration: "RelWithDebInfo"
>
> 1> running
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
> Release
>
> 1> -- Installing:
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
>
>
>
> So the message is there, but the script isn’t run.
>
>
>
> I’m I missing a dependency, or formatting the string incorrectly? How do I
> debug this?
>
>
>
> Thanks,
>
>
>
> Rob
>
>
>
>
>
> Rob Boehne
>
> Senior Software Architect | Datalogics, Inc.
>
> +1.312.853.8351 | r...@datalogics.com
>
> datalogics.com | blogs.datalogics.com
>
> Connect with us: Facebook | Twitter | LinkedIn | YouTube
>
>
>
>
>
> --
>
> 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] [EXTERNAL] Re: Linking to boost on OS X 10.12
The version of the libraries that you load from your build directory would need to be fixed up to. On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam wrote: > > Hi Robert, > > Thanks for your reply. We do use install_name_tool and the like when > installing/packaging, and our packages continue to work fine on OS X 10.12. > My question is about what to do with executables before packaging, while they > are still just in the build tree. We need them to work for purposes of > testing via CTest. > > Adam > > > On 2/5/19, 2:56 PM, "Robert Maynard" wrote: > > My general approach for the second problem is to run a tool such as > install_name_tool to change the library names to have @rpath when > constructing the package. > > On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake > wrote: > > > > Hello, > > > > > > > > The project I work on links to several shared boost libraries. After > our organization disallowed use of OS X 10.11 and we upgraded our built/test > slave to 10.12, we encountered a problem with our testing. Executables in the > build tree that were built as part of our project now fail to run with the > error that boost libraries can’t be found. > > > > > > > > Superficially, the problem is that (I think) Apple strengthened the SIP > between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – > previously the linker was able to locate the boost libs for our build tree > executables that way. > > > > > > > > The deeper problem is twofold: First, the build tree executables don’t > include the boost lib folder in their RPATHs. Second, the install names > embedded in boost libs themselves are just the bare filenames with no @rpath. > (My understanding is, the boost project does that deliberately because they > can’t know what users of their libraries will want.) > > > > > > > > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we > could use to embed the path to the boost libs into the build tree > executables. That doesn’t solve the second part of the problem, though. > Without embedding install names that look like @rpath/libboost_foo.dylib in > the build tree executables, I think the linker will still be unable to find > them. > > > > > > > > What is the best (or least bad) way to fix this? > > > > > > > > Thanks! > > > > > > > > Adam > > > > > > > > -- > > > > J. Adam Stephens, Ph.D. > > > > Dakota Support Analyst > > > > https://dakota.sandia.gov/ > > > > Optimization and UQ > > > > Sandia National Laboratories > > > > Albuquerque, NM > > > > > > > > -- > > > > 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] Linking to boost on OS X 10.12
My general approach for the second problem is to run a tool such as install_name_tool to change the library names to have @rpath when constructing the package. On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake wrote: > > Hello, > > > > The project I work on links to several shared boost libraries. After our > organization disallowed use of OS X 10.11 and we upgraded our built/test > slave to 10.12, we encountered a problem with our testing. Executables in the > build tree that were built as part of our project now fail to run with the > error that boost libraries can’t be found. > > > > Superficially, the problem is that (I think) Apple strengthened the SIP > between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – > previously the linker was able to locate the boost libs for our build tree > executables that way. > > > > The deeper problem is twofold: First, the build tree executables don’t > include the boost lib folder in their RPATHs. Second, the install names > embedded in boost libs themselves are just the bare filenames with no @rpath. > (My understanding is, the boost project does that deliberately because they > can’t know what users of their libraries will want.) > > > > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could > use to embed the path to the boost libs into the build tree executables. That > doesn’t solve the second part of the problem, though. Without embedding > install names that look like @rpath/libboost_foo.dylib in the build tree > executables, I think the linker will still be unable to find them. > > > > What is the best (or least bad) way to fix this? > > > > Thanks! > > > > Adam > > > > -- > > J. Adam Stephens, Ph.D. > > Dakota Support Analyst > > https://dakota.sandia.gov/ > > Optimization and UQ > > Sandia National Laboratories > > Albuquerque, NM > > > > -- > > 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] patches for MirOS
As a general policy CMake doesn't offer patch releases of older versions, and instead recommends updating to the latest CMake version. On Sun, Feb 3, 2019 at 10:21 PM Andrew Pennebaker wrote: > > Hiya! > > I got cmake to build in MirOS (also known as MirBSD) v10 this weekend, > painting over gaps in POSIX support. Here's my patchset: > > https://github.com/mcandre/vagrant-miros-cmake/tree/master/i386 > > Virtual machines are included for testing the patched build, and for testing > the final cmake binary. > > Note, this patchset targets cmake v3.9.0-. That's the first version I > happened to snag that doesn't depend on C++11 support. Evidently MirOS's > standard compiler, mgcc, has not offered C++11 support since it was released > way back during the 2008 financial crisis (!) > > Could we add these fixes to the 3.9 series so that MirOS users get better > access to cmake? > > -- > Cheers, > Andrew > -- > > 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] --warn-uninitialized works in only first configuration
Okay now I understand.
Yes this is the intended behavior of `--warn-uninitialized`.
It is designed so that it will only generate warnings for the explicit
invocation of cmake that includes the flag. Subsequent calls to
`cmake` without `--warn-uninitialized` will generate no warnings.
On Tue, Feb 5, 2019 at 12:08 PM Ramold, Felix wrote:
>
> It is not a cache variable. Here is an example:
>
> cmake_minimum_required(VERSION 3.10)
> project(TEST_UNINITIALIZED)
>
> file(WRITE dummy.cpp "")
> add_library(dummy dummy.cpp ${UNINITIALIZED})
>
> Also UNINITIALIZED is not added to CMakeCache.txt.
> Calling cmake twice (even without a change to the list) also shows this
> warning.
>
> -Ursprüngliche Nachricht-
> Von: Robert Maynard [mailto:robert.mayn...@kitware.com]
> Gesendet: Montag, 4. Februar 2019 18:16
> An: Ramold, Felix
> Cc: cmake@cmake.org
> Betreff: Re: [CMake] --warn-uninitialized works in only first configuration
>
> This generally occurs with CACHE variables as for non first runs they
> exist in the cache and therefore are initialized.
>
> On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix wrote:
> >
> > Hi,
> >
> >
> >
> > I configure a project with --warn-uninitialized and get a lot of warnings.
> > I successfully run the build.
> >
> > Then I change any CMakeLists.txt file. I run the build again. CMake checks
> > its dependencies and reconfigures before the actual build.
> >
> > Those warnings (or at least those in the edited file) don’t appear again.
> >
> > Is this the standard behavior?
> >
> >
> >
> > Thanks,
> >
> > Felix
> >
> > --
> >
> > 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] --warn-uninitialized works in only first configuration
This generally occurs with CACHE variables as for non first runs they exist in the cache and therefore are initialized. On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix wrote: > > Hi, > > > > I configure a project with --warn-uninitialized and get a lot of warnings. I > successfully run the build. > > Then I change any CMakeLists.txt file. I run the build again. CMake checks > its dependencies and reconfigures before the actual build. > > Those warnings (or at least those in the edited file) don’t appear again. > > Is this the standard behavior? > > > > Thanks, > > Felix > > -- > > 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
[cmake-developers] [ANNOUNCE] CMake 3.13.4 available for download
We are pleased to announce that CMake 3.13.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.13.4 since 3.13.3: Ben Boeckel (2): Tests: add cases for providing Qt5Core_VERSION manually AutoGen: query Qt5 version from directory properties Brad King (5): Revert "file: Allow DOWNLOAD/UPLOAD using alternate authentication methods" Intel: Record support for relaxed constexpr by version 18.0.5 macOS: Restore compatibility for setting FRAMEWORK after install() FindLAPACK: Distinguish check result variable name from FindBLAS CMake 3.13.4 Chuck Atkins (1): macOS: Add missing explicit dependency on CoreServices framework Craig Scott (3): cmake: Convert no source/build dir error to warning Help: Add 3.13.4 release note for no source/build dir error/warning FindDoxygen: Escape backslashes in default values -- 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-developers
[CMake] [ANNOUNCE] CMake 3.13.4 available for download
We are pleased to announce that CMake 3.13.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.13.4 since 3.13.3: Ben Boeckel (2): Tests: add cases for providing Qt5Core_VERSION manually AutoGen: query Qt5 version from directory properties Brad King (5): Revert "file: Allow DOWNLOAD/UPLOAD using alternate authentication methods" Intel: Record support for relaxed constexpr by version 18.0.5 macOS: Restore compatibility for setting FRAMEWORK after install() FindLAPACK: Distinguish check result variable name from FindBLAS CMake 3.13.4 Chuck Atkins (1): macOS: Add missing explicit dependency on CoreServices framework Craig Scott (3): cmake: Convert no source/build dir error to warning Help: Add 3.13.4 release note for no source/build dir error/warning FindDoxygen: Escape backslashes in default values -- 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-developers] [vtk-developers] CDash frontend refresh
My feeling on this is that the green should be stronger color. A fully green dashboard is a happy thing and it should make me the viewer happy :) I do get some less than ideal spacing and alignment ( see attached image ) around the `Items per page` and the `feed` On Thu, Jan 31, 2019 at 3:13 PM Dan Lipsa via vtk-developers wrote: > > Maybe the problem is the white text? > There isn't enough difference between the fairly pale color (red, yellow) and > the text color. > > Changing the text color to black might make it more readable and will make > the text that shows the number of errors (or warnings) consistent. > > On Thu, Jan 31, 2019 at 3:00 PM TJ Corona via vtk-developers > wrote: >> >> Hi Zack, >> >> I like the new layout! It’s very clean. Would it be possible to add an >> option to use the original table colors (green, yellow, red)? I can’t put my >> finger on why, but I find the new color palette more difficult to read. >> >> Sincerely, >> T.J. >> >> On Jan 31, 2019, at 1:53 PM, Zack Galbreath via vtk-developers >> wrote: >> >> We've been working on a refresh of CDash's look and feel. Before rolling >> this out, we wanted to give you all a sneak peek so that you could let us >> know what you think. >> >> Our proposed changes are now live on http://testing.cdash.org, which shares >> a backend database with https://open.cdash.org. >> >> For example, >> old: https://open.cdash.org/index.php?project=VTK >> new: http://testing.cdash.org/index.php?project=VTK >> >> This is inevitably a work in progress so future tweaks should be expected. >> That being said, please let us know if you see anything that seems like an >> obvious defect to you. >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://vtk.org/mailman/listinfo/vtk-developers >> >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://vtk.org/mailman/listinfo/vtk-developers >> > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://vtk.org/mailman/listinfo/vtk-developers > -- 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-developers
Re: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?)
I like some syntax that looks like $LEN{}.
I would love to keep the $...{ syntax open for future exentsion such
as easy target property set/get ( $[prop_name]{target} ) . This seems
to be okay as $ENV, and $CACHE only work on variables, so therefore
adding $LEN that also only works on variables seems reasonable.
On Tue, Jan 22, 2019 at 7:46 AM Brad King via cmake-developers
wrote:
>
> On 1/22/19 7:40 AM, Daniel Franke wrote:
> > Whats about a Syntax like
> >
> > ${list::LENGTH}
>
> That would require dispatch after matching `${VAR}` syntax, and
> that lookup is one of the hottest paths according to profiling.
> We already have $ENV{} and $CACHE{} syntax.
>
> -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:
> https://cmake.org/mailman/listinfo/cmake-developers
--
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-developers
