[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
not be fixed without breaking compatibility, and so have been superseded. Other Changes = * The "file API" index file now emits a "multiConfig" flag specifying whether or not the generator supports multiple output configurations. * 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 "MinGW Makefiles" generator no longer issues an error if "sh.exe" is present in the environment’s "PATH". * 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. * With SDCC the "sdar" tool is now preferred over "sdcclib" as librarian. The latter was deprecated by SDCC 3.2.0 and removed in SDCC 3.8.6. * With SDCC the default flags no longer include any target-specific flags. Previously the default flags were hard-coded for 8051. * The "CMAKE_VS_GLOBALS" variable value now applies during compiler identification and in targets created by the "add_custom_target()" command. * The "Xcode" generator no longer hard-codes "-Wmost", "-Wno-four- char-constants", and "-Wno-unknown-pragmas" warning flags. Changes made since CMake 3.17.0-rc2: Betsy McPhail (1): CTest: Fix our internal CURL_DEBUGFUNCTION to conform to CURL docs Bo Anderson (1): FindPython: Convert env CMAKE_FRAMEWORK_PATH to CMake path Brad King (5): Help: Clarify add_custom_command DEPENDS conversion to file paths Help: Fix toctree order of Xcode scheme variable and property Help: Fix 3.17 release notes for Xcode scheme settings macOS: Rename OSX_*_VERSION properties to MACHO_*_VERSION CMake 3.17.0-rc3 Craig Scott (1): Help: Cleanup minor typos and grammar in 3.17 release notes Jesse Gorzinski (1): libuv: Add support for building on IBM i (OS400) Kyle Edwards (2): Ninja Multi-Config: Don't build target dependencies for custom commands Ninja Multi-Config: Fix spurious unused variable warning Marc Chevrier (2): FindPython: python_add_library can now manage SOABI suffix. Apple Clang: add flags for C++17 standard Raul Tambre (2): cm_cxx_features: Filter out CUDA installation warnings cmAlgorithms: Fix -Wnon-c-typedef-for-linkage warnings Robert Maynard (1): CUDAToolkit: Mark find queries as advanced variables Saleem Abdulrasool (3): Swift: support Ninja Multi-Config Swift: repair RPATH handling for macOS Swift: Fix quoting of library search paths with spaces ThePrez (1): cmstd: Remove -isystem option for IBM i (OS400) Thomas Bernard (1): llvm-rc: Forward DEFINES instead of FLAGS -- 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.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
IES" 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 "MinGW Makefiles" generator no longer issues an error if "sh.exe" is present in the environment’s "PATH". * 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. * With SDCC the "sdar" tool is now preferred over "sdcclib" as librarian. The latter was deprecated by SDCC 3.2.0 and removed in SDCC 3.8.6. * With SDCC the default flags no longer include any target-specific flags. Previously the default flags were hard-coded for 8051. * The "CMAKE_VS_GLOBALS" variable value now applies during compiler identification and in targets created by the "add_custom_target()" command. * The "Xcode" generator no longer hard-codes "-Wmost", "-Wno-four- char-constants", and "-Wno-unknown-pragmas" warning flags. Changes made since CMake 3.17.0-rc1: Brad King (4): Help: Replace UTF-8 apostrophe with ascii apostrophe KWSys: SystemTools: CopyFileIfDifferent: Fix endless recursion KWSys: Terminal: Add st-256color to VT100 color support whitelist CMake 3.17.0-rc2 Craig Scott (3): Tests: Fix test_clean target missing some test directories Tests: Add missing ExternalProject smoke tests ExternalProject: Quote each git --config option to handle spaces Cristian Adam (1): PCH: Copy the timestamp from an absolute header file Francisco Facioni (1): Ninja: Do not use nvcc response files with non-nvcc tools Kyle Edwards (14): Ninja Multi-Config: Fix issue with framework dependencies and Autogen Refactor: Require detail when calling cmCTestRunTest::StartFailure() CTest: Improve error reporting with bad working directory for tests Refactor: Provide more detailed error information from TryAllocateResources() CTest: Provide more detailed information on resource allocation error Tests: Fix CustComDepend test for Ninja Multi-Config Tests: Fix CFBundleTest for Ninja Multi-Config Help: Note that CMAKE_CFG_INTDIR is not fully supported on Ninja Multi-Config Help: Clarify that the CTest resource allocation feature doesn't oversubscribe Ninja Multi-Config: Remove "NMC" from variable names Generator: Don't allow Ninja Multi-Config variables on other generators Ninja Multi-Config: Always generate build.ninja foreach: Fix crash when parsing invalid integer foreach: Set fatal error on invalid range Marc Chevrier (2): FindPython: Mark non-public cache entries INTERNAL FindPython: Do not cache computed result variables Richard (1): Autogen: Recognize the new Q_NAMESPACE_EXPORT macro in AUTOMOC Robert Maynard (1): FindCUDA: Only depend on Threads::Threads on platforms that need it Rolf Eike Beer (2): FindPkgConfig: set policies CMP0054 and CMP0057 to new Tests: fix RunCMake.Make test when run on systems with non-english locale Saleem Abdulrasool (1): Swift: support `-rpath` for executables Sergey Larin (1): PCH: Clang: Update PCH usage flags to include original header -- 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] [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
ted by GTest 1.8.1. * The "project()" command no longer strips leading zeros in version components. See policy "CMP0096". * The Qt Compressed Help file is now named "CMake.qch", which no longer contains the release version in the file name. When CMake is upgraded in-place, the name and location of this file will remain constant. Tools such as IDEs, help viewers, etc. should now be able to refer to this file at a fixed location that remains valid across CMake upgrades. * "RPATH" entries are properly escaped in the generated CMake scripts used for installation. See policy "CMP0095". * When using "CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS" on Windows the auto- generated exports are now updated only when the object files providing the symbols are updated. Changes made since CMake 3.16.0-rc3: Alex Turbov (1): CPack: Remove CPACK_INSTALL_CMAKE_CONFIGURATIONS Arkadiusz Drabczyk (1): Tutorial: replace Unicode EN DASH with ASCII dash Ben Boeckel (3): Help: drop confusing reference to `if()` from `$` FindPostgreSQL: support version encoding used in pre-10 releases FindPostgreSQL: also search for libraries in the MacPorts suffix Brad King (20): CTest: Rename PROCESSES test property to RESOURCE_GROUPS CTest: Rename "Processes" lexer to "ResourceGroups" Help/dev: Update maintainer guide for Discourse transition cmGlobalXCodeGenerator: Mark known source locations Xcode: Fix generated references to CMakeLists.txt files CMakeCPack: Update Debian package contact email Help: Replace links to mailing lists with links to our Discourse Forum README: Update links to cmake.org pages README: Replace link to mailing list the CMake Discourse Forum CMakeSystemSpecificInformation: Replace mailing list with Discourse Forum FindBinUtils: Revert "Use the compiler to get the path to compiler tools" Help: Document target_precompile_headers genex with angle brackets CTestCoverageCollectGCOV: Fix typo in ctest_coverage_collect_gcov docs expat: Update script to get Expat 2.2.9 expat: Update CMake build for 2.2.9 Tests: Fix ExportImport PCH expectation on Cray Classic compiler Tests: Add RunCMake.CPackCommandLine case for multi-config package Tests: Organize Objective C/C++ test directories CPack: Restore support for custom package configuration templates CMake 3.16.0-rc4 Charles Barto (1): Help: Clarify load_cache documentation of first parameter Craig Scott (14): ForceToRelativePath: Fix spurious assertion when local path is root dir Help: list(REMOVE_ITEM) removes all instances, not just the first found Help: Typo and grammar fixes for file(GET_RUNTIME_DEPENDENCIES) Tutorial: clean up typos, grammar and formatting RPATH: Remove stray indent in generated file(RPATH_CHANGE) command Help: Fix inaccuracies in INSTALL_REMOVE_ENVIRONMENT_RPATH docs CTest: Rename hardware -> resources for CMake variables, command options cmCTestMultiProcessHandler: Rename resource locking functions CTest: Rename hardware -> resources for source code CTest: Rename hardware -> resources for RunCMake tests Help: Improve readability and fix inaccuracies in unity build docs Help: Reorganise target_precompile_headers() docs for readability Help: Provide guidance on INTERFACE for target_precompile_headers() Help: Clarify compile features handling for OBJC and OBJCXX Craig Sturdy (1): FindwxWidgets: Add support for wxQt Cristian Adam (13): PCH: Add support for OBJC/OBJCXX languages CMakeVersion.rc: Fix build with llvm-rc ObjC: Mark explicitly the language for compilation Unity build: Include GENERATED files into unity build ObjC: Set same settings for all languages supported on Darwin ObjC: Add try_compile support PCH: No repeated path for internal generated PCH files Unity: Don't include sources with HEADER_FILE_ONLY property set ObjC: Document ObjC/ObjCXX standard properties / variables ObjC: Add OBJC/OBJCXX flags to Xcode projects ObjC: Initialize ObjC/XX standard properties from C/C++ counterparts ObjC: Proper initialization of ObjC/XX standard properties PCH: Do not issue an error on duplicate target_precompile_headers call Daniel Eiband (2): cmFileAPI: Resolve full path in PCH source comparison UnityBuild: Resolve full paths of unity source includes Deniz Bahadir (1): FindBoost: Prevent warning due to new meta-component "ALL" of Boost 1.73 Expat Upstream (1): expat 2019-09-25 (a7bc26b6) Grant Kim (1): FindwxWidgets: Add link dependencies for MinGW Kyle Edwards (2): Help: Fix error in resource allocation example Tests: Fix reliance on undefined behavior of cm::optional Marc Aldorasi (2): Help: Reference IMPORTED_IMPLIB from the IMPORTED_LOCATION documentation Help: Both add_custom_command signatures support COMMAND_EXPAND_LISTS Mateusz Janek (1): source_group: ensure that passed file is not a directory Robert Maynard (3): Help: Remove out of date bounds on compile feature supported versions find_package: Add support for CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY Help: Clarify what 'aware' means as it relates to C++ standards Saleem Abdulrasool (3): Swift: Allow build and installed RPATHs to differ Swift: support `INSTALL_NAME_DIR` on Darwin Swift: support `-rpath` on Darwin Tomasz Słodkowicz (1): FindwxWidgets: Add support for 3.1.3 VS binaries -- 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-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
Re: [CMake] How to specify VS2017 compilers when on VS2019
You can use that method so you get the IDE features of VS2019 but the VS2017 compiler. On Fri, Aug 16, 2019 at 2:19 PM Michael Jackson wrote: > > Why can't I do -T v141? > > -- > Mike Jackson > > On 8/16/19, 2:09 PM, "Kyle Edwards" wrote: > > On Fri, 2019-08-16 at 13:54 -0400, Michael Jackson wrote: > > What are the values to the -T argument that are to be used so that I > > can use VS2019 but have the 2017 compilers? > > Rather than using a -T argument, you want to set the CC environment > variable or -DCMAKE_C_COMPILER on the command line (likewise for CXX > and CMAKE_CXX_COMPILER.) > > Kyle > > > > -- > > 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] Ways to require CUDA arch minimum version?
Are you asking for a minimum CUDA SDK version or a restriction based on the hardware of the machine? We have no pre-built logic to enforce a minimum hardware component, as we want to support building CUDA on a machine without a GPU. As far as minimum CUDA SDK is concerned if you are doing it through find_package(CUDA) you would check the version after and error out if not high enough As farm as CUDA as a first class language, you can check the CMAKE_CUDA_COMPILER_VERSION and error out. On Thu, Aug 15, 2019 at 9:34 PM Hong Xu wrote: > > Is there a way to enforce a minimum CUDA arch version when finding CUDA? > Hong > > -- > > 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.15.2 available for download
We are pleased to announce that CMake 3.15.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.15.2 since 3.15.1: Brad King (8): Swift: Restore support for enabling with INTERFACE libraries VS: Fix mapping of `-Qspectre-` flag source_group: Fix regression in relative FILES clang: Restore support for clang-cl on non-Windows hosts fileapi: Fix codemodel target install destination for cross-dir rules clang: Work around toolchain file use of internal CMake variables Help: Add 3.15.2 release notes CMake 3.15.2 Claudio Fantacci (3): FindGLEW: Fix macOS library suffix selection FindGLEW: Add required OpenGL dependency in macOS FindGLEW: Fix typo in verbose log message Cristian Adam (1): find_package: Fix prefer-config mode to not fail on missing optional package -- 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.2 available for download
We are pleased to announce that CMake 3.15.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.15.2 since 3.15.1: Brad King (8): Swift: Restore support for enabling with INTERFACE libraries VS: Fix mapping of `-Qspectre-` flag source_group: Fix regression in relative FILES clang: Restore support for clang-cl on non-Windows hosts fileapi: Fix codemodel target install destination for cross-dir rules clang: Work around toolchain file use of internal CMake variables Help: Add 3.15.2 release notes CMake 3.15.2 Claudio Fantacci (3): FindGLEW: Fix macOS library suffix selection FindGLEW: Add required OpenGL dependency in macOS FindGLEW: Fix typo in verbose log message Cristian Adam (1): find_package: Fix prefer-config mode to not fail on missing optional package -- 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-developers] [ANNOUNCE] CMake 3.15.1 available for download
We are pleased to announce that CMake 3.15.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.15.1 since 3.15.0: Betsy McPhail (1): CTest: Generate Done.xml before calculating its hash Brad King (7): VS: Place intermediate files in the "ASM List Location" next to objects MSVC: Document behavior when MSVC_RUNTIME_LIBRARY is not set Clang: For MSVC ABI do not use modes older than C++14 Tests: Revert "require C++14 for the Tutorial" Makefile: Fix regression in dependencies on relative includes Help: Add 3.15.1 release notes CMake 3.15.1 James Butler (2): IRSL: Fix typo in v143 toolset version check IRSL: Fix discovery of VS 2019 v141 toolset redistributables Marc Chevrier (1): FindPython: ensure interpreter is founded when cross-compiling Marek Antoniak (1): Fix allocation in CROSSCOMPILING_EMULATOR evaluation Robert Maynard (2): FindMPI: Updated to use INTERFACE_LINK_OPTIONS FindMPI: make sure computed link flags are not de-duplicated Saleem Abdulrasool (5): Support per-language library link flags Swift: Add library search paths for dependencies Swift: add rules for static linking Swift: support multithreaded compilation Swift: support SONAME on ELFish 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-developers
[CMake] [ANNOUNCE] CMake 3.15.1 available for download
We are pleased to announce that CMake 3.15.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.15.1 since 3.15.0: Betsy McPhail (1): CTest: Generate Done.xml before calculating its hash Brad King (7): VS: Place intermediate files in the "ASM List Location" next to objects MSVC: Document behavior when MSVC_RUNTIME_LIBRARY is not set Clang: For MSVC ABI do not use modes older than C++14 Tests: Revert "require C++14 for the Tutorial" Makefile: Fix regression in dependencies on relative includes Help: Add 3.15.1 release notes CMake 3.15.1 James Butler (2): IRSL: Fix typo in v143 toolset version check IRSL: Fix discovery of VS 2019 v141 toolset redistributables Marc Chevrier (1): FindPython: ensure interpreter is founded when cross-compiling Marek Antoniak (1): Fix allocation in CROSSCOMPILING_EMULATOR evaluation Robert Maynard (2): FindMPI: Updated to use INTERFACE_LINK_OPTIONS FindMPI: make sure computed link flags are not de-duplicated Saleem Abdulrasool (5): Support per-language library link flags Swift: Add library search paths for dependencies Swift: add rules for static linking Swift: support multithreaded compilation Swift: support SONAME on ELFish 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
Re: [CMake] Shortcomings with exporting and importing targets
In general you match every find_package call in your project with one in your generate config file. If you have complicated conditional dependencies you might be able to use file(GENERATE to determine which ones will be used. On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote: > > > It is than up to each project to generate an Config module that does > the required find_package calls to re-locate ZLIB. > > Problems begin when mentioned dependencies are wrapped into generator > expressions (e.g. $ or smth even more > complicated) -- how do I know what `find_packages` to include to my > `*-config.cmake`?? > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard > wrote: >> >> target_link_libraries() when given an explicit path+filename as PUBLIC >> ( not PRIVATE ) will be part of the transitive dependencies. An >> explicit path+filename is not a target to CMake, nor will CMake >> compute that it maps to an existing target ( be it imported or a >> 'normal' target ). >> >> > This makes me think that install(TARGETS ...) not supporting imported >> > targets is likely an oversight by the CMake developers >> >> When exporting targets CMake exports what import targets something it >> depends on. So if you have target_link_libraries(my_target PUBLIC >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on >> ZLIB::ZLIB. It does this so that export information is machine >> relocatable. >> It is than up to each project to generate an Config module that does >> the required find_package calls to re-locate ZLIB. >> >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick >> wrote: >> > >> > As a followup to my previous email dated 7/15/19, I learned from a >> > co-worker this week that if Project A's target_link_libraries() links >> > against an explicit path+filename of an external library, a subsequent >> > install(TARGETS ...) command will actually include that dependency in the >> > exported target for Library A1, such that it will be picked up as a >> > transitive dependency when later linking Library A1 into a binary in >> > Project B. >> > >> > This makes me think that install(TARGETS ...) not supporting imported >> > targets is likely an oversight by the CMake developers. This ought to be >> > fixed, because it effectively discourages people from following the >> > "modern CMake" approach of using targets wherever possible. >> > -- >> > >> > 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] Shortcomings with exporting and importing targets
target_link_libraries() when given an explicit path+filename as PUBLIC ( not PRIVATE ) will be part of the transitive dependencies. An explicit path+filename is not a target to CMake, nor will CMake compute that it maps to an existing target ( be it imported or a 'normal' target ). > This makes me think that install(TARGETS ...) not supporting imported targets > is likely an oversight by the CMake developers When exporting targets CMake exports what import targets something it depends on. So if you have target_link_libraries(my_target PUBLIC ZLIB::ZLIB) CMake when exporting my_target will export it depends on ZLIB::ZLIB. It does this so that export information is machine relocatable. It is than up to each project to generate an Config module that does the required find_package calls to re-locate ZLIB. On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick wrote: > > As a followup to my previous email dated 7/15/19, I learned from a co-worker > this week that if Project A's target_link_libraries() links against an > explicit path+filename of an external library, a subsequent install(TARGETS > ...) command will actually include that dependency in the exported target for > Library A1, such that it will be picked up as a transitive dependency when > later linking Library A1 into a binary in Project B. > > This makes me think that install(TARGETS ...) not supporting imported targets > is likely an oversight by the CMake developers. This ought to be fixed, > because it effectively discourages people from following the "modern CMake" > approach of using targets wherever possible. > -- > > 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] add_subdirectory namespaces
Subsequent calls to project() from sub-directories is supported. For calls to project from sub-directories it does everything but set CMAKE_PROJECT_NAME. On Wed, Jul 24, 2019 at 7:29 AM Jason Beach wrote: > > I've been reorganizing / updating our software cmake build. It currently uses > a mixture of Externa Projects and normal target definitions that depend on > the external projects (which has you probably know causes much sorrow and > grief). One of my goals in the reorganization was to replace all the > ExternalProjectAdd statements with FetchContent, however I soon discovered > that some of the external projects declare targets with the same name (i.e. > an uninstall target). These external projects are third party libraries that > are not under our control. > > It appears there's been a suggestion to add namespaces to the > add_subdirectory command: > https://gitlab.kitware.com/cmake/cmake/issues/16414 > > Is that going anywhere? It seems like that would address FetchContent's main > limitation. I guess for the time being I'll use ExternalProject for > thirdparty libraries not under our control and FetchContent for libraries > that are and do a true super build instead of the muddled sort of arrangement > we have now. > > One other kind of not-so-random question-the documentation on the Project > statement is fine if it's in the toplevel CMakeLists.txt (in which case it > defines some project level variables, etc.) but it's silent about what > happens if it's not in the top level CMakeLists.txt. i.e. if I add a library > via add_subdirectory or FetchContent and that library's toplevel > CMakeLists.txt has the project statement, what happens when it's executed? > Is it silently ignored? > > Thanks, > Jason > -- > > 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 compiler's include paths
The history behind the makefile generator and the custom dependency tracking logic was that it was written before the majority of compilers offered a robust way to generate the list of header dependencies. As it stands now we want to remove all this custom dependency scanning logic, not extend it to understand system headers ( As the naive approach would cause CMake to parse system headers, and slow down even more ). Luckily, C++20 modules also require us to drop the custom dependency scanning, so when we add C++20 module support to the Makefile generator this issue will be fixed as by product. On Wed, Jul 3, 2019 at 10:51 AM Robert Maynard wrote: > > I completely forgot that the Makefiles based generators in CMake have > a separate heuristic for determining system headers. > > If you use the Ninja generator I see the expected behavior: > ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array > ~/W/t/nbuild $ ninja -d explain -v > ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older > than most recent input /usr/include/c++/7/array (1562165327 vs > 1562165329) > ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty > ninja explain: test/ProjTest is dirty > [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT > test/CMakeFiles/ProjTest.dir/test.cpp.o -MF > test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o > test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp > [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o > -o test/ProjTest && : > > > I will need to spend some more time figuring out the extra include > caching logic for the Makefile based generators, and will report back. > > On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: > > > > thanks for the anwer > > quite not... I'm using cmake 3.14.2 (so, far away from 3.6) and have a > > look, in main.cpp, there is #include : > > > > $ find /usr/include/ -name filesystem > > /usr/include/c++/5/experimental/filesystem > > /usr/include/c++/7/experimental/filesystem > > /usr/include/c++/8/filesystem > > /usr/include/c++/8/experimental/filesystem > > $ sudo touch /usr/include/c++/5/experimental/filesystem > > /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem > > /usr/include/c++/8/experimental/filesystem > > $ make > > [100%] Built target FileSync > > $ touch ../main.cxx > > $ make > > Scanning dependencies of target FileSync > > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o > > [100%] Linking CXX executable FileSync > > [100%] Built target FileSync > > > > > > => cmake don't create "full include dependency" which IS a mistake > > updating system g++ can just assume the target is uptodate and in fact just > > create a broken build... > > > > in cmake cxx.includecache > > > > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) > > #IncludeRegexScan: ^.*$ > > #IncludeRegexComplain: ^$ > > #IncludeRegexTransform: > > /home/orange/crypt/Devel/projets/FileSync/main.cxx > > cstdio > > - > > io.h > > - > > fcntl.h > > - > > locale > > - > > clocale > > - > > fstream > > - > > iostream > > - > > filesystem > > - > > > > $ /usr/bin/gcc-8 -M ../main.cxx > > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ > > /usr/include/c++/8/cstdio \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ > > /usr/x86_64-linux-gnu/include/features.h \ > > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ > > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ > > /usr/x86_64-linux-gnu/include/bits/long-double.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ > > /usr/x86_64-linux-gnu/include/stdio.h \ > > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ > > /usr/x86_64-linux-gnu/include/bits/types.h \ > > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/libio.h \ > > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ > > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h
Re: [CMake] relative path to toolchain does not work
Is this with a clean build directory? The toolchain file is ignored once CMake has run and has done compiler detection. On Wed, Jul 17, 2019 at 11:29 AM hex wrote: > > I specified my toolchain like so: > > 1cmake -DCMAKE_TOOLCHAIN_FILE=myToolchain.cmake .. > > and created a toolchain file in project/myToolchain.cmake. > > Using relative path CMake first looks relative to the top of the build > directory, then if not found there, relative to the top of the source > directory. > > What means “the top of the source directory”? I placed the file in the source > directory and receive: > > 1234CMake Warning: > Manually-specified variables were not used by the project: > > CMAKE_TOOLCHAIN_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 -- 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.0 available for download
I am happy to announce that CMake 3.15.0 is now available for download at: 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
[CMake] [ANNOUNCE] CMake 3.15.0 available for download
I am happy to announce that CMake 3.15.0 is now available for download at: 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
[cmake-developers] [ANNOUNCE] CMake 3.14.6 available for download
We are pleased to announce that CMake 3.14.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.14.6 since 3.14.5: Brad King (1): CMake 3.14.6 Brian Carlson (1): FindBISON: Fix CMP0088 NEW behavior for non-absolute input paths Chuck Atkins (1): Cray: Fix include parsing when the -hlist= flag is present Marc Chevrier (1): Android: ensure PIE behavior is consistent regardless CMP0083 policy -- 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.6 available for download
We are pleased to announce that CMake 3.14.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.14.6 since 3.14.5: Brad King (1): CMake 3.14.6 Brian Carlson (1): FindBISON: Fix CMP0088 NEW behavior for non-absolute input paths Chuck Atkins (1): Cray: Fix include parsing when the -hlist= flag is present Marc Chevrier (1): Android: ensure PIE behavior is consistent regardless CMP0083 policy -- 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.0-rc4 is ready for testing
_OVERRIDE". This can be used to specify the
current version of your source tree rather than using the update
command to discover the current version that is checked out.
CPack
-
* The "CPack IFW Generator" gained a new
"CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
stylesheet.
Deprecated and Removed Features
===
* 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.
* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property
instead.
* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
deprecated. Support still exists but will be removed in future
versions.
* The "export(PACKAGE)" command now does nothing unless enabled via
"CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".
* The "Xcode" generator now requires at least Xcode 5.
* An explicit deprecation diagnostic was added for policy "CMP0066"
("CMP0065" and below were already deprecated). The "cmake-
policies(7)" manual explains that the OLD behaviors of all policies
are deprecated and that projects should port to the NEW behaviors.
Other Changes
=
* CMake learned how to compile C++14 with the IBM AIX XL compiler
and the SunPro compiler and to compile C++20 with the AppleClang
compiler.
* With MSVC-like compilers the value of "CMAKE__FLAGS" no
longer contains warning flags like "/W3" by default. See policy
"CMP0092".
* IBM Clang-based XL compilers that define "__ibmxl__" now use the
compiler id "XLClang" instead of "XL". See policy "CMP0089".
* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
changed to ignore empty arguments with a warning instead of treating
them as a relative path and removing the contents of the current
directory.
Changes made since CMake 3.15.0-rc3:
Alex Turbov (1):
list(POP_FRONT): Fix always assigning first item to output vars
Brad King (4):
expat: Update script to get Expat 2.2.7
FindPostgreSQL: Fix regression in computation of library directory
cmGlobalGenerator: Do not persist alias targets across configures
CMake 3.15.0-rc4
Chuck Atkins (1):
Cray: Fix include parsing when the -hlist= flag is present
Craig Scott (8):
Help: Remove self-references from project() docs
Help: move code injection vars to their own section
Help: Clean up trivial typos and grammar
Help: Improve formatting of list(TRANSFORM) sub-options
Help: Add missing xref for CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
Help: Clarify how to provide multiple targets with cmake --target
Help: Remove mention of CMAKE_INSTALL_DO_STRIP
Help: Use consistent levels for cmake --loglevel and message()
Expat Upstream (1):
expat 2019-06-19 (d3b78b42)
Frank Dana (1):
message() help: Clarify how logs are displayed in various tools
Oleg Chernovskiy (1):
Help: Discourage using CMAKE_SOURCE_DIR in toolchain files
Robert Maynard (2):
CUDA: Do not device link if CUDA is not an enabled language
CUDA: Restore device linking to imported static library targets
Sebastian Holtermann (2):
Tests: Autogen: Use valid rcc compression levels
QtDialog: Use QPalette::WindowText instead of QPalette::Foreground
Stefan Andersson (1):
IAR: Add support for the RISC-V compiler
--
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.0-rc4 is ready for testing
_OVERRIDE". This can be used to specify the
current version of your source tree rather than using the update
command to discover the current version that is checked out.
CPack
-
* The "CPack IFW Generator" gained a new
"CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
stylesheet.
Deprecated and Removed Features
===
* 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.
* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property
instead.
* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
deprecated. Support still exists but will be removed in future
versions.
* The "export(PACKAGE)" command now does nothing unless enabled via
"CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".
* The "Xcode" generator now requires at least Xcode 5.
* An explicit deprecation diagnostic was added for policy "CMP0066"
("CMP0065" and below were already deprecated). The "cmake-
policies(7)" manual explains that the OLD behaviors of all policies
are deprecated and that projects should port to the NEW behaviors.
Other Changes
=
* CMake learned how to compile C++14 with the IBM AIX XL compiler
and the SunPro compiler and to compile C++20 with the AppleClang
compiler.
* With MSVC-like compilers the value of "CMAKE__FLAGS" no
longer contains warning flags like "/W3" by default. See policy
"CMP0092".
* IBM Clang-based XL compilers that define "__ibmxl__" now use the
compiler id "XLClang" instead of "XL". See policy "CMP0089".
* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
changed to ignore empty arguments with a warning instead of treating
them as a relative path and removing the contents of the current
directory.
Changes made since CMake 3.15.0-rc3:
Alex Turbov (1):
list(POP_FRONT): Fix always assigning first item to output vars
Brad King (4):
expat: Update script to get Expat 2.2.7
FindPostgreSQL: Fix regression in computation of library directory
cmGlobalGenerator: Do not persist alias targets across configures
CMake 3.15.0-rc4
Chuck Atkins (1):
Cray: Fix include parsing when the -hlist= flag is present
Craig Scott (8):
Help: Remove self-references from project() docs
Help: move code injection vars to their own section
Help: Clean up trivial typos and grammar
Help: Improve formatting of list(TRANSFORM) sub-options
Help: Add missing xref for CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
Help: Clarify how to provide multiple targets with cmake --target
Help: Remove mention of CMAKE_INSTALL_DO_STRIP
Help: Use consistent levels for cmake --loglevel and message()
Expat Upstream (1):
expat 2019-06-19 (d3b78b42)
Frank Dana (1):
message() help: Clarify how logs are displayed in various tools
Oleg Chernovskiy (1):
Help: Discourage using CMAKE_SOURCE_DIR in toolchain files
Robert Maynard (2):
CUDA: Do not device link if CUDA is not an enabled language
CUDA: Restore device linking to imported static library targets
Sebastian Holtermann (2):
Tests: Autogen: Use valid rcc compression levels
QtDialog: Use QPalette::WindowText instead of QPalette::Foreground
Stefan Andersson (1):
IAR: Add support for the RISC-V compiler
--
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 compiler's include paths
I am not an user of ctags. But CMake supports generating a `compile_commands.json` for the Makefile and Ninja generator ( https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html ). That will have all the include directories for each target. On Sun, Jul 7, 2019 at 10:27 AM jl forums wrote: > > ok, thanks > by the way what about my ctags rule? how can i get the include path of an > app? so that i can pass it to ctags and have my tags produced? > thanks and regards > jlm > > Le mer. 3 juil. 2019 à 16:52, Robert Maynard a > écrit : >> >> I completely forgot that the Makefiles based generators in CMake have >> a separate heuristic for determining system headers. >> >> If you use the Ninja generator I see the expected behavior: >> ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array >> ~/W/t/nbuild $ ninja -d explain -v >> ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older >> than most recent input /usr/include/c++/7/array (1562165327 vs >> 1562165329) >> ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty >> ninja explain: test/ProjTest is dirty >> [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT >> test/CMakeFiles/ProjTest.dir/test.cpp.o -MF >> test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o >> test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp >> [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o >> -o test/ProjTest && : >> >> >> I will need to spend some more time figuring out the extra include >> caching logic for the Makefile based generators, and will report back. >> >> On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: >> > >> > thanks for the anwer >> > quite not... I'm using cmake 3.14.2 (so, far away from 3.6) and have a >> > look, in main.cpp, there is #include : >> > >> > $ find /usr/include/ -name filesystem >> > /usr/include/c++/5/experimental/filesystem >> > /usr/include/c++/7/experimental/filesystem >> > /usr/include/c++/8/filesystem >> > /usr/include/c++/8/experimental/filesystem >> > $ sudo touch /usr/include/c++/5/experimental/filesystem >> > /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem >> > /usr/include/c++/8/experimental/filesystem >> > $ make >> > [100%] Built target FileSync >> > $ touch ../main.cxx >> > $ make >> > Scanning dependencies of target FileSync >> > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o >> > [100%] Linking CXX executable FileSync >> > [100%] Built target FileSync >> > >> > >> > => cmake don't create "full include dependency" which IS a mistake >> > updating system g++ can just assume the target is uptodate and in fact >> > just create a broken build... >> > >> > in cmake cxx.includecache >> > >> > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) >> > #IncludeRegexScan: ^.*$ >> > #IncludeRegexComplain: ^$ >> > #IncludeRegexTransform: >> > /home/orange/crypt/Devel/projets/FileSync/main.cxx >> > cstdio >> > - >> > io.h >> > - >> > fcntl.h >> > - >> > locale >> > - >> > clocale >> > - >> > fstream >> > - >> > iostream >> > - >> > filesystem >> > - >> > >> > $ /usr/bin/gcc-8 -M ../main.cxx >> > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ >> > /usr/include/c++/8/cstdio \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ >> > /usr/x86_64-linux-gnu/include/features.h \ >> > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ >> > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ >> > /usr/x86_64-linux-gnu/include/bits/long-double.h \ >> > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ >> > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ >> > /usr/x86_64-linux-gnu/include/stdio.h \ >> > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ >> > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ >> > /usr/x86_64-linux-gnu/include/bits/types.h \ >> > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/FILE.h
Re: [CMake] getting compiler's include paths
lude/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \
> /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \
> /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \
> /usr/include/c++/8/bits/streambuf.tcc \
> /usr/include/c++/8/bits/streambuf_iterator.h \
> /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \
> /usr/include/c++/8/bits/locale_facets.tcc \
> /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \
> /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \
> /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \
> /usr/x86_64-linux-gnu/include/libintl.h \
> /usr/include/c++/8/bits/codecvt.h \
> /usr/include/c++/8/bits/locale_facets_nonio.tcc \
> /usr/include/c++/8/bits/locale_conv.h \
> /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \
> /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \
> /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \
> /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \
> /usr/include/c++/8/istream /usr/include/c++/8/ios \
> /usr/include/c++/8/bits/basic_ios.h \
> /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \
> /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc \
> /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \
> /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \
> /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \
> /usr/include/c++/8/filesystem
>
>
> amazing, no? cmake find only 9 dependencies against 100+ real ones (and I
> don't even speak of errors that can be caused in parsing if some -D option is
> changed
>
> thanks and regards
> JLM
>
>
> Le lun. 24 juin 2019 à 14:14, Robert Maynard a
> écrit :
>>
>> It look that starting with CMake 3.6 modification of system headers
>> will cause CMake to recompile projects. What version of CMake and your
>> compiler are you using?
>>
>> On Mon, Jun 17, 2019 at 9:40 AM jl forums wrote:
>> >
>> > Hi,
>> > I want to create a full tag file and for this require to know the compiler
>> > full include path... there is a way to had custom includes path but
>> > didn't found any variables for the include path
>> > for example :
>> > $ gcc-8 -v -x c -E /dev/null
>> > Using built-in specs.
>> > []
>> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> > /usr/lib/gcc/x86_64-linux-gnu/8/include
>> > /usr/local/include
>> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
>> > /usr/x86_64-linux-gnu/include
>> > /usr/include/x86_64-linux-gnu
>> > /usr/include
>> > End of search list.
>> > [...]
>> >
>> > $ gcc -v -x c -E /dev/null
>> > Using built-in specs.
>> > [...]
>> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> > /usr/lib/gcc/x86_64-linux-gnu/7/include
>> > /usr/local/include
>> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
>> > /usr/x86_64-linux-gnu/include
>> > /usr/include/x86_64-linux-gnu
>> > /usr/include
>> > End of search list.
>> > [...]
>> >
>> > I tried to
>> >
>> >
>> > get_target_property(moggle_interface_includes FileSync
>> > INTERFACE_INCLUDE_DIRECTORIES)
>> > message("Moggle interface includes: ${moggle_interface_includes}")
>> >
>> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
>> > message("MOTOR includes ${motor_includes}")
>> >
>> > but I get
>> >
>> > Moggle interface includes: moggle_interface_includes-NOTFOUND
>> > MOTOR includes motor_includes-NOTFOUND
>> >
>> >
>> > there is also some issue because cmake strip dependencies from system's
>> > include, which means that updating a system software won't cause rebuild
>> > and consider that the build is uptodate, causing unexpected results
>> > seems that there is ways to workaround this :
>> > https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake
>> > but this is ugly... would be better to let the user choose with an option
>> >
>> > thanks and regards
>> > JLM
>> > --
>> >
>> > 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] compiling .cpp/.cxx with CUDA compiler
In general I go with the source property approach, since you can pass
it a collection of files to be marked as CUDA.
If you are aware of when all sources have been added to a target you
can easily mark them all as cuda with:
get_target_property(source_files SOURCES)
set_source_files_properties(${source_files} PROPERTIES LANGUAGE CUDA)
As far as changing the mapping of file extensions to languages, as far
as I am aware that is currently unsupported.
On Tue, Jul 2, 2019 at 2:19 PM Kai Germaschewski
wrote:
>
> For background, a bunch of projects help writing portable C++ code that can
> be compiled into CUDA device code as one option, e.g. hemi, kokkos, RAJA
> (https://devblogs.nvidia.com/simple-portable-parallel-c-hemi-2/). As a
> consequence, if available those source files need to be compiled with the
> CUDA compiler, but with the regular C++ compiler otherwise.
>
> I'm wondering whether there is a clean way to support this in a cmake build.
> Renaming my source files to `.cu` is bad if I'm on the system without CUDA. I
> figured out that I can set the LANGUAGE property on a given .cpp/.cxx source
> file to CUDA to have it compiled with CMAKE_CUDA_COMPILER, but that's quite a
> hassle to do for every source file. Kokkos instead creates a `nvcc_wrapper`
> script which one is supposed to use as CMAKE_CXX_COMPILER, but that
> definitely seems like a kludge to me (and giving me troubles).
>
> Things would probably be much better for me if there was a way to change the
> default language for .cxx / .cpp extensions. Is there a way to do this?
>
> --Kai
>
>
>
> --
>
> 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.15.0-rc3 is ready for testing
I am proud to announce the third 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-rc3 is ready for testing
I am proud to announce the third 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.
Re: [CMake] getting compiler's include paths
It look that starting with CMake 3.6 modification of system headers
will cause CMake to recompile projects. What version of CMake and your
compiler are you using?
On Mon, Jun 17, 2019 at 9:40 AM jl forums wrote:
>
> Hi,
> I want to create a full tag file and for this require to know the compiler
> full include path... there is a way to had custom includes path but didn't
> found any variables for the include path
> for example :
> $ gcc-8 -v -x c -E /dev/null
> Using built-in specs.
> []
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/8/include
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
> /usr/x86_64-linux-gnu/include
> /usr/include/x86_64-linux-gnu
> /usr/include
> End of search list.
> [...]
>
> $ gcc -v -x c -E /dev/null
> Using built-in specs.
> [...]
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/7/include
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
> /usr/x86_64-linux-gnu/include
> /usr/include/x86_64-linux-gnu
> /usr/include
> End of search list.
> [...]
>
> I tried to
>
>
> get_target_property(moggle_interface_includes FileSync
> INTERFACE_INCLUDE_DIRECTORIES)
> message("Moggle interface includes: ${moggle_interface_includes}")
>
> get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
> message("MOTOR includes ${motor_includes}")
>
> but I get
>
> Moggle interface includes: moggle_interface_includes-NOTFOUND
> MOTOR includes motor_includes-NOTFOUND
>
>
> there is also some issue because cmake strip dependencies from system's
> include, which means that updating a system software won't cause rebuild and
> consider that the build is uptodate, causing unexpected results
> seems that there is ways to workaround this :
> https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake
> but this is ugly... would be better to let the user choose with an option
>
> thanks and regards
> JLM
> --
>
> 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.0-rc2 is ready for testing
RIDE". This can be used to specify the
current version of your source tree rather than using the update
command to discover the current version that is checked out.
CPack
-
* The "CPack IFW Generator" gained a new
"CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
stylesheet.
Deprecated and Removed Features
===
* 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.
* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property
instead.
* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
deprecated. Support still exists but will be removed in future
versions.
* The "export(PACKAGE)" command now does nothing unless enabled via
"CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".
* The "Xcode" generator now requires at least Xcode 5.
* An explicit deprecation diagnostic was added for policy "CMP0066"
("CMP0065" and below were already deprecated). The "cmake-
policies(7)" manual explains that the OLD behaviors of all policies
are deprecated and that projects should port to the NEW behaviors.
Other Changes
=
* CMake learned how to compile C++14 with the IBM AIX XL compiler
and the SunPro compiler and to compile C++20 with the AppleClang
compiler.
* With MSVC-like compilers the value of "CMAKE__FLAGS" no
longer contains warning flags like "/W3" by default. See policy
"CMP0092".
* IBM Clang-based XL compilers that define "__ibmxl__" now use the
compiler id "XLClang" instead of "XL". See policy "CMP0089".
* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
changed to ignore empty arguments with a warning instead of treating
them as a relative path and removing the contents of the current
directory.
Changes made since CMake 3.15.0-rc1:
Alexander Grund (5):
Tests.FindBoost: Don't use BoostConfig in MODULE test
Tests.RunCMake.FindBoost: Fix example BoostConfig
FindBoost: Don't overwrite Boost_${_comp}_FOUND
FindBoost: Add legacy variables and targets for compatibility
FindBoost: Add tests for legacy variables
Alexander Neumann (1):
FindBLAS: Add second try for OpenBLAS with thread libraries.
Brad King (8):
Help: Document XLClang compiler id
fileapi: Factor out helper to construct a version object
cmake: Simplify implementation of -E capabilities
cmake: Teach -E capabilities to report supported fileapi requests
cmake-gui: Update Qt copyright holder in About dialog
fileapi: Suppress lint warning about non-move with old jsoncpp
Help: Document what project() calls use CMAKE_PROJECT_INCLUDE and friends
CMake 3.15.0-rc2
Craig Scott (2):
Help: Trivial typo and grammar fixes for FindEnvModules
Help: Move ADDITIONAL_MAKE_CLEAN_FILES dir prop to deprecated section
Cristian Adam (1):
find_package: Fixed CMAKE_FIND_PACKAGE_PREFER_CONFIG Module fallback
Marc Chevrier (1):
Android: ensure PIE behavior is consistent regardless CMP0083 policy
Mathieu Malaterre (1):
CPack/NuGet: Find nuget tool on case sensitive file system
Robert Maynard (1):
FindMPI: Store imported target link flags as a list instead of a string
Rolf Eike Beer (1):
CheckCXXSymbolExists: reference to CheckCXXSourceCompiles instead of C version
Sebastian Holtermann (2):
Autogen: Fix header detection for paths with symbolic links
Help: Improve ADDITIONAL_CLEAN_FILES documentation
--
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.0-rc2 is ready for testing
RIDE". This can be used to specify the
current version of your source tree rather than using the update
command to discover the current version that is checked out.
CPack
-
* The "CPack IFW Generator" gained a new
"CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
stylesheet.
Deprecated and Removed Features
===
* 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.
* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property
instead.
* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
deprecated. Support still exists but will be removed in future
versions.
* The "export(PACKAGE)" command now does nothing unless enabled via
"CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".
* The "Xcode" generator now requires at least Xcode 5.
* An explicit deprecation diagnostic was added for policy "CMP0066"
("CMP0065" and below were already deprecated). The "cmake-
policies(7)" manual explains that the OLD behaviors of all policies
are deprecated and that projects should port to the NEW behaviors.
Other Changes
=
* CMake learned how to compile C++14 with the IBM AIX XL compiler
and the SunPro compiler and to compile C++20 with the AppleClang
compiler.
* With MSVC-like compilers the value of "CMAKE__FLAGS" no
longer contains warning flags like "/W3" by default. See policy
"CMP0092".
* IBM Clang-based XL compilers that define "__ibmxl__" now use the
compiler id "XLClang" instead of "XL". See policy "CMP0089".
* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
changed to ignore empty arguments with a warning instead of treating
them as a relative path and removing the contents of the current
directory.
Changes made since CMake 3.15.0-rc1:
Alexander Grund (5):
Tests.FindBoost: Don't use BoostConfig in MODULE test
Tests.RunCMake.FindBoost: Fix example BoostConfig
FindBoost: Don't overwrite Boost_${_comp}_FOUND
FindBoost: Add legacy variables and targets for compatibility
FindBoost: Add tests for legacy variables
Alexander Neumann (1):
FindBLAS: Add second try for OpenBLAS with thread libraries.
Brad King (8):
Help: Document XLClang compiler id
fileapi: Factor out helper to construct a version object
cmake: Simplify implementation of -E capabilities
cmake: Teach -E capabilities to report supported fileapi requests
cmake-gui: Update Qt copyright holder in About dialog
fileapi: Suppress lint warning about non-move with old jsoncpp
Help: Document what project() calls use CMAKE_PROJECT_INCLUDE and friends
CMake 3.15.0-rc2
Craig Scott (2):
Help: Trivial typo and grammar fixes for FindEnvModules
Help: Move ADDITIONAL_MAKE_CLEAN_FILES dir prop to deprecated section
Cristian Adam (1):
find_package: Fixed CMAKE_FIND_PACKAGE_PREFER_CONFIG Module fallback
Marc Chevrier (1):
Android: ensure PIE behavior is consistent regardless CMP0083 policy
Mathieu Malaterre (1):
CPack/NuGet: Find nuget tool on case sensitive file system
Robert Maynard (1):
FindMPI: Store imported target link flags as a list instead of a string
Rolf Eike Beer (1):
CheckCXXSymbolExists: reference to CheckCXXSourceCompiles instead of C version
Sebastian Holtermann (2):
Autogen: Fix header detection for paths with symbolic links
Help: Improve ADDITIONAL_CLEAN_FILES documentation
--
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] How to specify debug version of CRT library for Visual Studio generator?
Just a heads up, CMake 3.15 is introducing policy 91 which removes the
runtime library from the default set of flags, and instead has targets
establish what runtime they want.
For more information see:
https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html
On Tue, Jun 18, 2019 at 10:06 AM Eric Dönges wrote:
>
> On 18.06.19 12:53, David Aldrich wrote:
> > I have a simple CMake project that builds an executable using Visual
> > Studio 2017:
>
>
> >
> > Files
> > # -- Add files to project. -- #
> > ###
> >
> > file(GLOB SRC_FILES
> > ${CPP_DIR_1}/*.cpp
> > ${CPP_DIR_2}/*.cpp
> > ${CPP_DIR_3}/*.cpp
> > ${CPP_DIR_4}/*.cpp
> > ${HEADER_DIR_1}/*.h
> > )
> >
> > # Add executable to build.
> > add_executable(${PROJECT_NAME}
> >${SRC_FILES}
> > )
> >
> > if(MSVC)
> >target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > endif(MSVC)
> >
> > #=
> >
> > The Release build succeeds but the Debug build fails with linker errors
> > such as:
> >
> > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > __imp___CrtDbgReport
> >
> > I think this is because the linker is not using the debug version of CRT
> > (C Run-time Library).
> >
> > Should CMake select the debug build of CRT automatically or do I need to
> > specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
> >
>
> CMake will select the correct CRT automatically if you let it (unless
> you want the static CRT, in which case you have to override CMake's
> default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG incorrectly:
>
> > if(MSVC)
> >#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > /MD /Od /Zi /EHsc")
> >set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > /Oi /Gy /Zi /EHsc")
> >set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > /GL /Od /Oi /Gy /Zi /EHsc")
> > endif(MSVC)
>
> In case of the setting you've commented out, you are explicitly telling
> CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> since you append the /MD, that is what the compiler will actually use.
>
> For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> you want (and also specifies /MD).
>
> I would suggest looking at what flags CMake sets by default (look at the
> Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> only setting those flags that CMake doesn't already. For version 3.14,
> CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> default (assuming you are using MVSC >= 1310, no Clang toolset):
>
> /MDd /Zi /Ob0 /Od /GR /EHSC
>
> So in your case, it would probably be enough to
>
> string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
>
> As a final recommendation, use string(APPEND ...) (or list(APPEND
> ...), if the variable is interpreted as a list) when appending
> values to existing variables. This makes your intent clearer.
>
>
> - when appending compiler flags, use the "string(APPEND ...)" command
> to make is clearer what you are doing).
> --
>
> 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.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 "
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
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 >
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
