From claus.klein at arcormail.de Mon Mar 5 14:32:18 2018 From: claus.klein at arcormail.de (Claus Klein) Date: Mon, 5 Mar 2018 20:32:18 +0100 Subject: [cmake-developers] Platform/MINGW64_NT-6.1: can't bootstrap cmake Message-ID: <173B9EC9-AB8A-4F97-A66E-5CFF926F2404@arcormail.de> Hi, I have problems to build cmake an msys2. It can be found at http://www.msys2.org. With regards Claus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmake--system-information.txt URL: -------------- next part -------------- From brad.king at kitware.com Mon Mar 5 14:59:34 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 5 Mar 2018 14:59:34 -0500 Subject: [cmake-developers] Platform/MINGW64_NT-6.1: can't bootstrap cmake In-Reply-To: <173B9EC9-AB8A-4F97-A66E-5CFF926F2404@arcormail.de> References: <173B9EC9-AB8A-4F97-A66E-5CFF926F2404@arcormail.de> Message-ID: <0f83a064-4772-e4e7-5589-fd17ac604a6c@kitware.com> On 03/05/2018 02:32 PM, Claus Klein wrote: > I have problems to build cmake an msys2. > It can be found at http://www.msys2.org. We have nightly testing for MSYS2's MinGW toolchain that compiles to a native Windows binary, including the bootstrap script: https://open.cdash.org/testDetails.php?test=631628857&build=5278231 I think MSYS2 provides a package for a CMake that uses the MSYS2 runtime library, but there is no upstream support for that currently. -Brad From claus.klein at arcormail.de Mon Mar 5 15:20:40 2018 From: claus.klein at arcormail.de (Claus Klein) Date: Mon, 5 Mar 2018 21:20:40 +0100 Subject: [cmake-developers] Platform/MINGW64_NT-6.1: can't bootstrap cmake In-Reply-To: <0f83a064-4772-e4e7-5589-fd17ac604a6c@kitware.com> References: <173B9EC9-AB8A-4F97-A66E-5CFF926F2404@arcormail.de> <0f83a064-4772-e4e7-5589-fd17ac604a6c@kitware.com> Message-ID: Yes, cmake is available, but it is patched: https://github.com/Alexpux/MSYS2-packages/tree/master/cmake But there are messages about an unknown system and I should send you the system-information. I tried to but the nightly build cmake sources with this msys2 cmake and it failed to build. So I tried to bootstrap cmake, same result. Claus > Am 05.03.2018 um 20:59 schrieb Brad King : > > I think MSYS2 provides a package for a CMake that uses the MSYS2 > runtime library, but there is no upstream support for that currently. From craig.scott at crascit.com Thu Mar 8 03:16:42 2018 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 8 Mar 2018 19:16:42 +1100 Subject: [cmake-developers] Non-failing BuildDepends has make errors Message-ID: See the end of this sample test output: https://open.cdash.org/testDetails.php?test=604789995&build=5286961 The test is passing, but it ends with a build failure trying to build a "clean" target that doesn't exist in the Makefile2 file (it *does* exist in the top level Makefile in my local build when I was checking this test). Is this behaviour expected? This only seems to happen in Makefile builds, including nmake (platform doesn't seem to matter). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Mar 8 09:08:30 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 8 Mar 2018 09:08:30 -0500 Subject: [cmake-developers] Non-failing BuildDepends has make errors In-Reply-To: References: Message-ID: <1ceb523f-86bf-4d4e-fc0e-111c120cd0dd@kitware.com> On 03/08/2018 03:16 AM, Craig Scott wrote: > The test is passing, but it ends with a build failure trying to build Currently `cmGlobalGenerator::Build` doesn't check the return code from the "make clean" step and just moves on to "make". It fails only if there is a problem launching the build tool. I'm not sure whether this is preferred or should be changed. Theoretically "make clean" should never fail except in the presence of bugs like that below. > a "clean" target that doesn't exist in the Makefile2 file That's a bug triggered when there are no targets. See fix: https://gitlab.kitware.com/cmake/cmake/merge_requests/1833 Thanks, -Brad From robert.maynard at kitware.com Fri Mar 9 14:00:25 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 9 Mar 2018 14:00:25 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing Message-ID: I am proud to announce the third CMake 3.11 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc2: Brad King (3): XL: Recognize compilers identified by __ibmxl__ CUDA: Do not pass unsupported @rspfile arguments to NVCC CMake 3.11.0-rc3 KWSys Upstream (1): KWSys 2018-03-07 (2ad561e7) Sebastian Holtermann (1): Autogen: Check if a file is empty before reading it From rcdailey.lists at gmail.com Mon Mar 12 16:11:28 2018 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 12 Mar 2018 15:11:28 -0500 Subject: [cmake-developers] How to obtain a list of target dependencies In-Reply-To: References: Message-ID: I'm going to add the CMake Dev group as well, since I asked this same question last year around May and I didn't get any response. Hoping for some help this time around. I don't see anything documented, so maybe the developers know the best approach here. On Mon, Mar 12, 2018 at 3:03 PM, Robert Dailey wrote: > Sometimes I need to manually take action on the dependencies of my > targets. Without keeping track of the dependencies externally using > global or custom target properties, is there a way to obtain the list > of targets that a target depends on? This would be the same list of > targets passed to `target_link_libraries()`. For bonus points I'd like > a flattened list of transitive dependencies, to avoid recursively > building this list myself. From ben.boeckel at kitware.com Mon Mar 12 16:39:53 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 12 Mar 2018 16:39:53 -0400 Subject: [cmake-developers] How to obtain a list of target dependencies In-Reply-To: References: Message-ID: <20180312203953.GA20978@megas.kitware.com> On Mon, Mar 12, 2018 at 15:11:28 -0500, Robert Dailey wrote: > I'm going to add the CMake Dev group as well, since I asked this same > question last year around May and I didn't get any response. Hoping > for some help this time around. I don't see anything documented, so > maybe the developers know the best approach here. There's an issue for this here: https://gitlab.kitware.com/cmake/cmake/issues/12435 There has been extensive discussion on the feature and previous mailing list threads about it. I'm not intimately familiar with that discussion myself, but it has more details at least. --Ben From robert.maynard at kitware.com Fri Mar 16 10:14:50 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 16 Mar 2018 10:14:50 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.3 available for download Message-ID: We are pleased to announce that CMake 3.10.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.10.3 since 3.10.2: Brad King (1): CMake 3.10.3 Craig Scott (1): GoogleTest: Rename TIMEOUT parameter to avoid clash Sebastian Holtermann (1): Autogen: Fix for the empty source file crash in 3.10.2 Tianhao Chai (1): ccmake: fix status line buffer overflow on very wide terminals From craig.scott at crascit.com Fri Mar 16 18:51:23 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 17 Mar 2018 09:51:23 +1100 Subject: [cmake-developers] Fwd: [CMake] Cmake Frameworks and Bitcode In-Reply-To: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: Forwarding to the developers list since it probably can best be answered there. ---------- Forwarded message ---------- From: Cameron Palmer Date: Tue, Mar 13, 2018 at 1:36 AM Subject: [CMake] Cmake Frameworks and Bitcode To: "cmake at cmake.org" So after a bit of hacking it seems that Cmake should provide something like: CMAKE_OSX_BITCODE_ENABLE Which would pass -fembed-bitcode to the compiler and linker and remove the option in Darwin.cmake for -Wl,-headerpad_max_install_names in CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS. Does this sound like something that should be submitted as a patch? -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sat Mar 17 01:29:03 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 16 Mar 2018 22:29:03 -0700 (PDT) Subject: [cmake-developers] set_target_properties documentation needs to be updated Message-ID: I just noticed (at ) the following inconsistent documentation of set_target_properties: "Targets can have properties that affect how they are built. set_target_properties(target1 target2 ... PROPERTIES prop1 value1 prop2 value2 ...) Set properties on a target. The syntax for the command is to list all the files you want to change, and then provide the values you want to set next. You can use any prop value pair you want and extract it later with the get_property() or get_target_property() command. See Properties on Targets for the list of properties known to CMake." I believe this documentation needs to be updated. The principal issue is whether there is just a single target for this command (as indicated by the command name) or multiple targets. In the former case "target2 ..." should be removed and list all the files you want to change ==> specify the target you want to change In the latter case Set properties on a target ==> Set properties on targets and list all the files you want to change ==> list all the targets you want to change If somone here knows which case is correct, then I would be willing to make one or the other of the above sets of changes available as a git format-patch result, but I doubt that complication should be necessary since presumably anybody who knows that answer will be in a good position to do this simple documentation fix commit themselves. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Mon Mar 19 07:54:08 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 19 Mar 2018 07:54:08 -0400 Subject: [cmake-developers] [CMake] Cmake Frameworks and Bitcode In-Reply-To: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: On 03/12/2018 10:36 AM, Cameron Palmer wrote: > So after a bit of hacking it seems that Cmake should provide something like: > > CMAKE_OSX_BITCODE_ENABLE For reference, this refers to a previous post: Bitcode and CMake https://cmake.org/pipermail/cmake/2018-March/067191.html with the goal of using `-fembed-bitcode` while avoiding a warning: ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) > Which would pass -fembed-bitcode to the compiler and linker and remove > the option in Darwin.cmake for -Wl,-headerpad_max_install_names in > CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS. One may avoid the `-headerpad_max_install_names` option with this: https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html There is no reason to build with any rpath set for the build tree when one cannot run the binaries on the macOS host anyway. -Brad From brad.king at kitware.com Mon Mar 19 08:08:34 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 19 Mar 2018 08:08:34 -0400 Subject: [cmake-developers] set_target_properties documentation needs to be updated In-Reply-To: References: Message-ID: <355b15f6-1850-916d-31c6-865956f33a94@kitware.com> On 03/17/2018 01:29 AM, Alan W. Irwin wrote: > In the latter case > > Set properties on a target ==> Set properties on targets > > and > > list all the files you want to change ==> list all the targets you > want to change It is the latter. See MR here: https://gitlab.kitware.com/cmake/cmake/merge_requests/1866 Thanks, -Brad From robert.maynard at kitware.com Mon Mar 19 11:13:58 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 19 Mar 2018 11:13:58 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.11.0-rc4 is now ready for testing Message-ID: I am proud to announce the fourth CMake 3.11 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc3: Brad King (6): Genex: Fix COMPILE_LANGUAGE in SYSTEM include directories Genex: Fix COMPILE_LANGUAGE propagation through try_compile XL: Fix C default level detection when invoked as 'cc' Features: Record initializer list support for Intel 14 and above FindQt4: Revert "Set PLUGINS and IMPORTS dir even if empty" CMake 3.11.0-rc4 Craig Scott (1): GoogleTest: Rename TIMEOUT parameter to avoid clash Jean-Christophe Fillion-Robin (1): ExternalProject: Fix cache generation when last args ends with "-NOTFOUND" Kai Wolf (1): Help: Adapt cmake-buildsystem(7) to new IMPORTED targets features Tianhao Chai (1): ccmake: fix status line buffer overflow on very wide terminals YunQiang Su (1): FindJNI: add some new architecture names for mips release 6 From claus.klein at arcormail.de Tue Mar 20 03:05:56 2018 From: claus.klein at arcormail.de (Claus Klein) Date: Tue, 20 Mar 2018 08:05:56 +0100 Subject: [cmake-developers] How to get cmake to install pdb files for targets too? Message-ID: Hi, I am wondering why pdb file are not installed with a library target in MS VS2017 generated projects when building the Debug config variant? Is this relay necessary: install(FILES $ DESTINATION bin OPTIONAL) see too https://stackoverflow.com/questions/40860435/how-to-get-cmake-to-install-pdb-files-for-targets Why ist that install command not enough: install(TARGETS example EXPORT ExampleTargets RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR} LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} ) With regards Claus -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Richter at hogyros.de Tue Mar 20 06:35:43 2018 From: Simon.Richter at hogyros.de (Simon Richter) Date: Tue, 20 Mar 2018 11:35:43 +0100 Subject: [cmake-developers] How to get cmake to install pdb files for targets too? In-Reply-To: References: Message-ID: <43667d97-a57c-7bb0-1d9e-65816eb56cc2@hogyros.de> Hi, On 20.03.2018 08:05, Claus Klein wrote: > Hi, I am wondering why pdb file are not installed with a library target > in MS VS2017 generated projects when building the Debug config variant? Very few people install PDBs to the bin directory, that is an administrative nightmare (who is responsible for deleting them when you install a Release build with no PDBs on top?). Instead, I suggest installing into a separate directory which you either place on the symbol path or import the PDBs from into a regular symbol server. This doesn't even need a change to the CMakeLists.txt, just pass -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH= with the desired output path. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From craig.scott at crascit.com Wed Mar 21 18:01:42 2018 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 22 Mar 2018 09:01:42 +1100 Subject: [cmake-developers] INTERFACE IMPORTED example Message-ID: I swear I asked this a while back and there was an example given, but I have been unable to find it since. With changes done for CMake 3.11, I think the question deserves asking again anyway. Does anyone know of a specific example scenario where an INTERFACE IMPORTED library is the right choice over simply INTERFACE or IMPORTED on its own? I'm trying to understand what an "INTERFACE IMPORTED" library is primarily used for and it seems others are equally confused. Now that some of the restrictions around imported libraries have been relaxed , the differences seem even less obvious. Anyone able to put forward a scenario? If we can clarify this well, I'm happy to update the docs to make it clear for everyone (okay, and so I can find it again in the future :P ). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Mar 22 07:37:44 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 22 Mar 2018 07:37:44 -0400 Subject: [cmake-developers] INTERFACE IMPORTED example In-Reply-To: References: Message-ID: On 03/21/2018 06:01 PM, Craig Scott wrote: > I swear I asked this a while back and there was an example given Maybe here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/1581 > Does anyone know of a specific example scenario where an > INTERFACE IMPORTED library is the right choice over simply > INTERFACE or IMPORTED on its own? A non-INTERFACE imported target needs an IMPORTED_LOCATION, so an IMPORTED target wouldn't replace an INTERFACE IMPORTED target. A plain INTERFACE library and an IMPORTED INTERFACE library are nearly identical indeed, but the scope of the name differs. IMPORTED INTERFACE libraries mostly exist for install(EXPORT) to produce from an installed/exported INTERFACE library. They can't export as a normal INTERFACE library because imported targets have visibility isolated to the directory that imports them. -Brad From michal.wozniak at caboma.com Thu Mar 22 14:09:20 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Thu, 22 Mar 2018 18:09:20 +0000 Subject: [cmake-developers] CDash - upload Test.xml 500 Error Message-ID: Hi, I am trying to submit my project ctest result to our CDash instance but I'm getting an error during the submission. To make sure everything is setup correctly, I'm using the tutorial project from the CMake tutorial I have attended last week. Project - CMake_Tutorial\Step8 I have only changed CTEST_DROP_SITE to point to my own CDash instance. cmd : ctest -C "Release" -D Experimental --verbose I am getting a 500 Internal Server Error during the uploading of the Test.xml file. On CDash, I can see my submission with the Build & Configure information. [cid:8ccb5c8a-d09f-4e6d-9181-1dbe9c02aef4] Is there something I need to enable on my CDash instance? thank you Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 163863 bytes Desc: pastedImage.png URL: From zack.galbreath at kitware.com Thu Mar 22 15:40:48 2018 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 22 Mar 2018 15:40:48 -0400 Subject: [cmake-developers] CDash - upload Test.xml 500 Error In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 2:09 PM, Michal Wozniak wrote: > I am getting a 500 Internal Server Error during the uploading of the > Test.xml file. > > Is there something I need to enable on my CDash instance? > It should work out of the box. See if you can find more details about what's going wrong in your web server's error logs. For more detailed discussions about CDash, we can chat on the CDash mailing list . If you think you've found a bonafide bug, please open an issue on our GitHub project . -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Mar 22 16:26:35 2018 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 23 Mar 2018 07:26:35 +1100 Subject: [cmake-developers] INTERFACE IMPORTED example In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 10:37 PM, Brad King wrote: > On 03/21/2018 06:01 PM, Craig Scott wrote: > > I swear I asked this a while back and there was an example given > > Maybe here: > > * https://gitlab.kitware.com/cmake/cmake/merge_requests/1581 Yes, that was it, thanks. > > Does anyone know of a specific example scenario where an > > INTERFACE IMPORTED library is the right choice over simply > > INTERFACE or IMPORTED on its own? > > A non-INTERFACE imported target needs an IMPORTED_LOCATION, > so an IMPORTED target wouldn't replace an INTERFACE IMPORTED > target. > > A plain INTERFACE library and an IMPORTED INTERFACE library are > nearly identical indeed, but the scope of the name differs. > > IMPORTED INTERFACE libraries mostly exist for install(EXPORT) > to produce from an installed/exported INTERFACE library. > They can't export as a normal INTERFACE library because > imported targets have visibility isolated to the directory > that imports them. > Okay. So the use case is inside a package's installed config file? i.e. if a project wants to define an INTERFACE library to be provided as part of its package, it should be defining an INTERFACE IMPORTED library? And that's only needed because by convention, when someone does a find_package(), any targets created by that are usually expected to be imported targets with non-global scope, so an ordinary INTERFACE library is not quite right because it has global scope (which CMake would allow, but INTERFACE IMPORTED would be better). Following that through, the combination INTERFACE IMPORTED GLOBAL is probably of little use now, since either: - It doesn't need an IMPORTED_LOCATION, in which case a plain INTERFACE library is appropriate and arguably clearer/simpler. - It does need an imported location but since IMPORTED GLOBAL now supports setting interface properties, it could do the job and is also arguably clearer/simpler. Only for pre-CMake 3.11 would INTERFACE IMPORTED GLOBAL be useful, since IMPORTED GLOBAL didn't support setting interface properties before then. And it would only be useful for the case where IMPORTED_LOCATION was being set to point at a real library (otherwise just use INTERFACE on its own). If there are any holes or errors in that, please let me know. Thanks. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupp0r at gmail.com Fri Mar 23 12:33:28 2018 From: jupp0r at gmail.com (=?utf-8?Q?Jupp_M=C3=BCller?=) Date: Fri, 23 Mar 2018 09:33:28 -0700 Subject: [cmake-developers] ctest parallelism for --repeat-until-failure Message-ID: Hi, I have a question regarding the behavior of ctest with regard to the --repeat-until-failure option. It seems that this option sequentializes test execution for single tests in a test suite, while different tests can be run parallel to each other. Is this the desired behavior? This is causing delays for my test suite, because some long-running tests are sequentialized. Would you be willing to accept a contribution that changes this? I realize this would be a backwards compatibility issue, because running the same test in parallel would break some tests, so I'd propose adding a new flag to ctest that would be disabled by default. Maybe --parallelize-repetitions ? Thanks, Jupp Mueller From michal.wozniak at caboma.com Sat Mar 24 16:09:52 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Sat, 24 Mar 2018 20:09:52 +0000 Subject: [cmake-developers] CDash - upload Test.xml 500 Error In-Reply-To: References: , Message-ID: Hi, Something was wrong with my CDash installation. I think I had set some wrong permissions but I finally got it working! Didn't even know that there was a specific mailing list for CDash. thanks ________________________________ From: cmake-developers on behalf of Zack Galbreath Sent: Thursday, March 22, 2018 3:40:48 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] CDash - upload Test.xml 500 Error On Thu, Mar 22, 2018 at 2:09 PM, Michal Wozniak > wrote: I am getting a 500 Internal Server Error during the uploading of the Test.xml file. Is there something I need to enable on my CDash instance? It should work out of the box. See if you can find more details about what's going wrong in your web server's error logs. For more detailed discussions about CDash, we can chat on the CDash mailing list. If you think you've found a bonafide bug, please open an issue on our GitHub project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Mar 26 08:07:34 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 26 Mar 2018 23:07:34 +1100 Subject: [cmake-developers] Surprising CMP0054 behavior Message-ID: Am I missing something, or is the following result surprising to others as well: set(somevar YES) if ("somevar") message("Get here if CMP0054 is OLD (seems okay)") else() message("Get here if CMP0054 is NEW (surprising?)") endif() I would have thought that even with CMP0054 being NEW, the if condition would still evaluate to true since it is going to test a non-empty string that doesn't match any of the defined false constants. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 26 08:51:30 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Mar 2018 08:51:30 -0400 Subject: [cmake-developers] Surprising CMP0054 behavior In-Reply-To: References: Message-ID: <50382bbf-93cc-36c0-1f03-4a5f31af9d07@kitware.com> On 03/26/2018 08:07 AM, Craig Scott wrote: > Am I missing something, or is the following result surprising to others as well: > > set(somevar YES) > if ("somevar") > ? ? message("Get here if CMP0054 is OLD (seems okay)") > else() > ? ? message("Get here if CMP0054 is NEW (surprising?)") > endif() > > I would have thought that even with CMP0054 being NEW, the if condition would > still evaluate to true since it is going to test a non-empty string that > doesn't match any of the defined false constants. The observed behavior is consistent with the documentation. `if()` enumerates a set of true/false constants and says that if it is not one of these then it uses `if()`. That is true only if it is a variable that is defined to a value that is not a false constant. With CMP0054 NEW behavior, `if("string")` is always treated as the *string* variant which is never a variable defined to anything. -Brad From brad.king at kitware.com Mon Mar 26 09:19:13 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Mar 2018 09:19:13 -0400 Subject: [cmake-developers] [CMake] Cmake Frameworks and Bitcode In-Reply-To: References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: <27205fe9-602e-4280-19ac-7dbaf5e7becd@kitware.com> On 03/26/2018 04:24 AM, Cameron Palmer wrote: > However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't > change anything as far as I can tell. The target is still linked with > -headerpad_max_install_names and the linker still complains. Oops, I mixed up functionality with other platforms. On platforms that do not have `-headerpad_max_install_names` we generate bogus rpath content in the build tree to pad out enough space to replace it in the installed binary in the install tree. That behavior is turned off by BUILD_WITH_INSTALL_RPATH. On Apple platforms with `-headerpad_max_install_names` the flag is simply hard-coded. CMake would indeed need a new abstraction for `-fembed-bitcode`. Also, CMP0068 means the BUILD_WITH_INSTALL_NAME_DIR should be used instead of BUILD_WITH_INSTALL_RPATH. > Also, looking at policy 68 and working with the INSTALL_NAME, which > is the one thing you do care about, you cannot set the directory to > @rpath which seems silly. Sure we can. CMP0068 is only about the names of the CMake properties that influence the behavior. The INSTALL_NAME_DIR property can be set to "@rpath". -Brad From craig.scott at crascit.com Mon Mar 26 16:22:57 2018 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 27 Mar 2018 07:22:57 +1100 Subject: [cmake-developers] Surprising CMP0054 behavior In-Reply-To: <50382bbf-93cc-36c0-1f03-4a5f31af9d07@kitware.com> References: <50382bbf-93cc-36c0-1f03-4a5f31af9d07@kitware.com> Message-ID: On Mon, Mar 26, 2018 at 11:51 PM, Brad King wrote: > On 03/26/2018 08:07 AM, Craig Scott wrote: > > Am I missing something, or is the following result surprising to others > as well: > > > > set(somevar YES) > > if ("somevar") > > message("Get here if CMP0054 is OLD (seems okay)") > > else() > > message("Get here if CMP0054 is NEW (surprising?)") > > endif() > > > > I would have thought that even with CMP0054 being NEW, the if condition > would > > still evaluate to true since it is going to test a non-empty string that > > doesn't match any of the defined false constants. > > The observed behavior is consistent with the documentation. > > `if()` enumerates a set of true/false constants and says > that if it is not one of these then it uses `if()`. > That is true only if it is a variable that is defined to a value that > is not a false constant. With CMP0054 NEW behavior, `if("string")` > is always treated as the *string* variant which is never a variable > defined to anything. > Okay, but the net effect of that logic is that for the expression `if("${someVar}")`, if the value of `someVar` is neither a true nor false constant, it ends up evaluating to false. This seems the opposite of what it should be. Most languages generally take the path of if an expression doesn't evaluate to known false values, the result is true (a la C's "anything but 0 is considered true" approach). Even CMake's logic here tries to be like that - it's how the unary if() behaves when given a variable name rather than a quoted string (if the variable's value is not a false constant, the result is true). The fact that it's the opposite when given a string is the surprising part. Probably the only practical path forward here is to clarify the docs, but I'm still trying to wrap my head around how it could be explained without ending up making it look like a confusing mess. At the very least though, I think the docs for the CMP0054 policy needs an example specifically for this unary if() scenario. It's just that the explanation that should go with it is hard. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Mar 28 14:14:56 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 28 Mar 2018 14:14:56 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.11.0 available for download Message-ID: I am proud to announce that CMake 3.11.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc4: Brad King (5): Features: Record for SunPro 5.15 Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" cmSystemTools: Fix ParseArguments out-of-bounds read ctest_update: Fix crash when handling svn externals CMake 3.11.0 Roger Leigh (1): FindBoost: Add support for Boost 1.67 with Python version suffixes From michal.wozniak at caboma.com Thu Mar 29 14:38:03 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Thu, 29 Mar 2018 18:38:03 +0000 Subject: [cmake-developers] clang-tidy third party library exclude ? Message-ID: Hi, While reading this post, I thought of adding clang-tiny to our build process. Is it possible to exclude third-party libraries? Our application depends on VTK but I would like to ignore it during the static check. I saw that you can disable the check for each line with //NOLINT, but is there a process to disable all files in a third party folder? Thank you Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Mar 29 14:46:32 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Mar 2018 14:46:32 -0400 Subject: [cmake-developers] clang-tidy third party library exclude ? In-Reply-To: References: Message-ID: On 03/29/2018 02:38 PM, Michal Wozniak wrote: > I thought of adding clang-tiny to our build process. > Is it possible to exclude third-party libraries?? The variable used to activate it: https://cmake.org/cmake/help/v3.11/variable/CMAKE_LANG_CLANG_TIDY.html works by initializing a property used to activate it: https://cmake.org/cmake/help/v3.11/prop_tgt/LANG_CLANG_TIDY.html as each target is created. If in the third-party subdirectory you set the variable to empty then none of its targets will get the behavior. -Brad From michal.wozniak at caboma.com Thu Mar 29 15:20:49 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Thu, 29 Mar 2018 19:20:49 +0000 Subject: [cmake-developers] clang-tidy third party library exclude ? In-Reply-To: References: , Message-ID: Thank you, I will try this. Sent from Mail for Windows 10 ________________________________ From: Brad King Sent: Thursday, March 29, 2018 2:46:32 PM To: Michal Wozniak Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] clang-tidy third party library exclude ? On 03/29/2018 02:38 PM, Michal Wozniak wrote: > I thought of adding clang-tiny to our build process. > Is it possible to exclude third-party libraries? The variable used to activate it: https://cmake.org/cmake/help/v3.11/variable/CMAKE_LANG_CLANG_TIDY.html works by initializing a property used to activate it: https://cmake.org/cmake/help/v3.11/prop_tgt/LANG_CLANG_TIDY.html as each target is created. If in the third-party subdirectory you set the variable to empty then none of its targets will get the behavior. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: