From csiga.biga at aol.com Wed Oct 2 09:24:05 2019 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 2 Oct 2019 15:24:05 +0200 Subject: [cmake-developers] Revitalize --find-package mode? Message-ID: Hi! I?m currently struggling with trying to build GNOME projects using meson, but depending on CMake-built libraries, either in the wild or inside a package manager. I have managed to uncover that the way Meson is trying to invoke CMake https://github.com/microsoft/vcpkg/issues/6683#issuecomment-533034646 to obtain dependency information is no longer maintained in CMake, or at least discouraged for new projects. My queries on the Meson forums did not resonate well (in fact they didn?t resonate at all): https://groups.google.com/forum/#!topic/mesonbuild/OEB0UIlLl0A Are there any opinions in how to make ends meet? I?m trying to build GIMP on Ubuntu LTS releases, which often have outdated packages that cannot be used to build GNOME master branches as well as build them natively on Windows using Vcpkg ports. The current method Meson tries to use CMake is totally Vcpkg-unfriendly. As far as I saw --find-package mode and toolchain failes are not friends, even configuring a one-line main.cpp fails due to basic variables not being set in --find-package mode. What specific routes do you see viable? Best regards, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Oct 2 09:59:23 2019 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Oct 2019 09:59:23 -0400 Subject: [cmake-developers] Revitalize --find-package mode? In-Reply-To: <20191002132612.EE350127AA0@public.kitware.com> References: <20191002132612.EE350127AA0@public.kitware.com> Message-ID: <8a64916a-d347-c6ca-9efb-29abc6f88ee6@kitware.com> On 10/2/19 9:24 AM, Nagy-Egri M?t? Ferenc via cmake-developers wrote: > to obtain dependency information is no longer maintained in CMake, > or at least discouraged for new projects. For reference, the `cmake --find-package` mode documentation you mentioned is here: * https://cmake.org/cmake/help/v3.15/manual/cmake.1.html#run-the-find-package-tool "This mode is not well-supported due to some technical limitations. It is kept for compatibility but should not be used in new projects." There is an issue collecting some of the problems with it: * https://gitlab.kitware.com/cmake/cmake/issues/14676 There is another issue discussing a possible alternative: * https://gitlab.kitware.com/cmake/cmake/issues/17236 A key difference between the two approaches is that the latter actually enables languages and inspects the toolchain to support things like COMPILE_FEATURES and such. However, the way all that information is encoded in the imported targets created by `install(EXPORT)` is meant to be consumed and transformed by CMake's generators. It may not be easy to extract it for external use. I've just posted some additional links in the latter issue above: * https://gitlab.kitware.com/cmake/cmake/issues/17236#note_634094 -Brad From robert.maynard at kitware.com Wed Oct 2 13:00:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Oct 2019 13:00:00 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.14.7 available for download Message-ID: 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 From robert.maynard at kitware.com Wed Oct 2 13:10:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Oct 2019 13:10:00 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.15.4 available for download Message-ID: 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 From Alan.W.Irwin1234 at gmail.com Mon Oct 7 22:10:00 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 7 Oct 2019 19:10:00 -0700 (PDT) Subject: [cmake-developers] FindThreads module documentation needs some work Message-ID: In my opinion [the latest documentation of the FindThreads module](https://cmake.org/cmake/help/latest/module/FindThreads.html) needs some work. Specifically please deal with the following documentation issues. * Threads_FOUND needs documentation. And that needs to be done at the top of the documentation as typically happens with other modules where a _FOUND variable is being set on a successful find. * CMAKE_HAVE_THREADS_LIBRARY needs documentation. I suspect the value of this variable (set in the module but otherwise not used there) has been historically useful for those module users who have figured out its purpose, but it would be good to have that purpose documented. * The CMAKE_THREAD_LIBS_INIT variable and corresponding Threads::Threads INTERFACE_LINK_LIBRARIES target property is the empty string for the case when the (Posix) threads functions are provided by the C library. According to a second-hand report I received this case happens on Mac OS X (at least for MacPorts). Therefore, please document this expected result for that important use case. * Finally, for that same important use case THREADS_PREFER_PTHREAD_FLAG is completely ignored, and that should be documented as well. Because of these documentation issues, learning to use this module properly on both Linux and Mac OS X for PLplot and another project I have been working on has been much more work than I expected (i.e., instead of relying on documentation I had to analyze the CMake code in this module to figure out what was going on). I would be willing to repeat all the above in a bug report, but instead of doing that I hope someone here is willing to step forward with fixups for the above simple documentation issues in a timely manner so there is no bug triage burden for these fixups. Alan __________________________ Alan W. Irwin 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.org); 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 alexander.samoylov at gmail.com Tue Oct 8 08:10:08 2019 From: alexander.samoylov at gmail.com (Alexander) Date: Tue, 8 Oct 2019 14:10:08 +0200 Subject: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS Message-ID: Dear CMake Developers, I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS. I would like to know if this is an expected behaviour or a bug. I already asked in the users-thread, but nobody could answer me directly if it is bug or not. Original message: https://cmake.org/pipermail/cmake/2019-October/070031.html. -- Best Regards, Alexander Samoilov Build & Integration Engineer Compart AG, 71034 B?blingen Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Oct 8 10:57:22 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Oct 2019 10:57:22 -0400 Subject: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: Message-ID: <858bcf89-8355-5daa-020c-0a825c073c44@kitware.com> On 10/8/19 8:10 AM, Alexander wrote: > I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS. > I would like to know if this is an expected behaviour or a bug. A module definition file can be passed as a normal source file and CMake will automatically add `/DEF:...` to the link line as needed. -Brad From alexander.samoylov at gmail.com Wed Oct 9 18:04:35 2019 From: alexander.samoylov at gmail.com (Alexander) Date: Thu, 10 Oct 2019 00:04:35 +0200 Subject: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: <858bcf89-8355-5daa-020c-0a825c073c44@kitware.com> References: <858bcf89-8355-5daa-020c-0a825c073c44@kitware.com> Message-ID: In some cases it is not convenient to program something in CMakeFile.txt (for example when I clone some 3rd party project and want to change its build procedure). Thus the possibility to add additional .defs files with the help of *command line* options would be very nice. Such a command line option exists: -DMAKE_SHARED_LINKER_FLAGS, but it deliberately ignores /DEF: which makes impossible to add /DEF: this easy (and for me preferable) way. I would like to get an answer from CMake developers, if it is an expected behavior of MAKE_SHARED_LINKER_FLAGS. If yes: what is the logic behind it and why this special handling of MAKE_SHARED_LINKER_FLAGS is not documented on https://cmake.org/cmake/help/v3.15/variable/CMAKE_SHARED_LINKER_FLAGS.html. If no: issue a bug. -- Best Regards, Alexander Do it mean that On Tue, 8 Oct 2019 at 16:57, Brad King wrote: > On 10/8/19 8:10 AM, Alexander wrote: > > I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS. > > I would like to know if this is an expected behaviour or a bug. > > A module definition file can be passed as a normal source file and > CMake will automatically add `/DEF:...` to the link line as needed. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Oct 9 18:29:41 2019 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Oct 2019 18:29:41 -0400 Subject: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: <858bcf89-8355-5daa-020c-0a825c073c44@kitware.com> Message-ID: On 10/9/19 6:04 PM, Alexander wrote: > it deliberately ignores /DEF: which makes impossible to add /DEF: this easy > (and for me preferable) way. The code ``` string(APPEND CMAKE_SHARED_LINKER_FLAGS " -DEF:\"${CMAKE_CURRENT_SOURCE_DIR}/foo.def\"") ``` works fine for me. So does this: ``` target_link_options(mySharedLib PRIVATE "-DEF:${CMAKE_CURRENT_SOURCE_DIR}/foo.def") ``` -Brad From Alan.W.Irwin1234 at gmail.com Thu Oct 10 13:28:44 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 10 Oct 2019 10:28:44 -0700 (PDT) Subject: [cmake-developers] FindThreads module documentation needs some work In-Reply-To: References: Message-ID: I have [opened an issue on the bugtracker](https://gitlab.kitware.com/cmake/cmake/issues/19823) concerning this documentation bug. Alan __________________________ Alan W. Irwin 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.org); 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 wouter.klouwen at youview.com Wed Oct 16 10:05:30 2019 From: wouter.klouwen at youview.com (Wouter Klouwen) Date: Wed, 16 Oct 2019 14:05:30 +0000 Subject: [cmake-developers] CTest load balancing Message-ID: Hi all, CTest has a very useful feature that performs load balancing. This works by comparing the current system load to a target load. The current implementation defers to SystemInformationImplementation::GetLoadAverage() to return a value. This is implemented on the platforms that have getloadavg() by returning the first value of that. While this function is present on many UNIX platforms, on Linux it means something slightly different than on say Solaris and *BSD. Namely on the former it is representing a "system load" and on the latter it is "CPU load", which is a subtle but rather important distinction. The system load includes processes which are in the uninterruptable state on purpose, a rather interesting blog post by Brendan Gregg has some juicy details: http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html Now, this has recently become a problem for us, as on some of our systems there are some kernel level processes active that by design are in the uninterruptable state, therefore contributing to the system load average, even if they do not affect the CPU load of the system. The number of processes in this state can easily outnumber the number of cores (i.e. 11 uninterruptable processes vs 4 CPU threads). So an idle system can have a load of > 10, for instance. At present we are working around this by setting a higher load to manage the tests, this as you might imagine is not a perfect solution as the number of uninterruptable processes does vary over time. The implementation of this feature specifically mentions checking for CPU load, which to be consistent on all platforms would require checking slightly different details on Linux. Is the intent for CTest to specifically manage CPU load or system load overall? The original commit message and comments point more towards the former. The Windows implementation of GetLoadAverage() also points towards merely CPU load. A Linux specific implementation would have to, most likely, investigate /proc/stat and derive a CPU load from that. Any ideas/suggestions? Thanks, W This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com From brad.king at kitware.com Wed Oct 16 10:10:43 2019 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Oct 2019 10:10:43 -0400 Subject: [cmake-developers] CTest load balancing In-Reply-To: References: Message-ID: On 10/16/19 10:05 AM, Wouter Klouwen wrote: > Is the intent for CTest to specifically manage CPU load or system load > overall? I don't think a careful distinction was made at the time. If Linux needs some updates to be consistent with other platforms then that would be fine with me. -Brad From robert.maynard at kitware.com Sun Oct 20 13:25:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Sun, 20 Oct 2019 13:25:00 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing Message-ID: 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 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). Command-Line ------------ * "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. Commands -------- * The "add_test()" command learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * 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". * 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 "find_package()" command has learned to check the following variables to control searching * "CMAKE_FIND_USE_PACKAGE_REGISTRY" - Controls the searching the cmake user registry. * The "message()" command learned indentation control with the new "CMAKE_MESSAGE_INDENT" variable. * The "target_precompile_headers()" command was added to specify a list of headers to precompile for faster compilation times. Variables --------- * The "CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS" variable has been introduced to optionally initialize the "CUDA_RESOLVE_DEVICE_SYMBOLS" target property. * The "CMAKE_ECLIPSE_RESOURCE_ENCODING" variable was added to specify the resource encoding for the the "Eclipse CDT4" extra generator. Properties ---------- * The "BUILD_RPATH" and "INSTALL_RPATH" target properties now support "generator expressions". * The "INSTALL_REMOVE_ENVIRONMENT_RPATH" target property was added to remove compiler-defined "RPATH" entries from a target. This property is initialized by the "CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH" variable. * The "PRECOMPILE_HEADERS" target property was added to specify a list of headers to precompile for faster compilation times. Set it using the "target_precompile_headers()" command. * The "UNITY_BUILD" target property was added to tell generators to batch include source files for faster compilation times. * The "VS_CONFIGURATION_TYPE" target property now supports "generator expressions". * The "VS_DPI_AWARE" target property was added to tell Visual Studio Generators to set the "EnableDpiAwareness" property in ".vcxproj" files. * The "XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING" target property was added to tell the "Xcode" generator to set the value of the "Allow debugging when using document Versions Browser" schema option. Modules ------- * The "FindDoxygen" module "doxygen_add_docs()" command gained a new "USE_STAMP_FILE" option. When this option present, the custom target created by the command will only re-run Doxygen if any of the source files have changed since the last successful run. * The "FindGnuTLS" module now provides an imported target. * The "FindPackageHandleStandardArgs" module "find_package_handle_standard_args()" command gained a new "REASON_FAILURE_MESSAGE" option to specify a message giving the reason for the failure. * The "FindPkgConfig" module "pkg_search_module()" macro now defines a "_MODULE_NAME" result variable containing the first matching module name. * The "FindPython3" and "FindPython" modules gained options to control which "ABIs" will be searched. * The "FindPython3", "FindPython2", and "FindPython" modules now support direct specification of artifacts via cache entries. Autogen ------- * When using "AUTOMOC", CMake now generates the "-p" path prefix option for "moc". This ensures that "moc" output files are identical on different build setups (given, that the headers compiled by "moc" are in an "include directory"). Also it ensures that "moc" output files will compile correctly when the source and/or build directory is a symbolic link. The "moc" path prefix generation behavior can be configured by setting the new "CMAKE_AUTOMOC_PATH_PREFIX" variable and/or "AUTOMOC_PATH_PREFIX" target property. CTest ----- * "ctest(1)" now has the ability to serialize tests based on hardware requirements for each test. See Hardware Allocation for details. * A new test property, "SKIP_REGULAR_EXPRESSION", has been added. This property is similar to "FAIL_REGULAR_EXPRESSION" and "PASS_REGULAR_EXPRESSION", but with the same meaning as "SKIP_RETURN_CODE". This is useful, for example, in cases where the user has no control over the return code of the test. For example, in Catch2, the return value is the number of assertion failed, therefore it is impossible to use it for "SKIP_RETURN_CODE". CPack ----- * CPack variable "CPACK_INSTALL_CMAKE_CONFIGURATIONS" was added to control what configurations are to be packaged for multi- configuration CMake generators. * The "CPack DEB Generator" is now able to format generic text (usually used as the description for multiple CPack generators) according to the Debian Policy Manual. See the "CPACK_PACKAGE_DESCRIPTION_FILE" and "CPACK_DEBIAN__DESCRIPTION" variables. * The "CPack Archive Generator" learned to generate ".tar.zst" packages with Zstandard compression. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policy "CMP0067" ("CMP0066" 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 "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)". * The "CPACK_INSTALL_SCRIPT" variable has been deprecated in favor of the new, more accurately named "CPACK_INSTALL_SCRIPTS" variable. Other Changes ============= * The "cmake(1)" "-C " option now evaluates the initial cache script with "CMAKE_SOURCE_DIR" and "CMAKE_BINARY_DIR" set to the top-level source and build trees. * The "cmake(1)" "-E remove_directory" command-line tool, when given the path to a symlink to a directory, now removes just the symlink. It no longer removes content of the linked directory. * The "ctest(1)" "--build-makeprogram" command-line option now specifies the make program used when configuring a project with the "Ninja" generator or the Makefile Generators. * The "ExternalProject" module "ExternalProject_Add()" command has been updated so that "GIT_SUBMODULES """ initializes no submodules. See policy "CMP0097". * The "FindGTest" module has been updated to recognize MSVC build trees generated 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-rc1: Ben Boeckel (2): FindPostgreSQL: support version 12 FindPostgreSQL: support macports installation scheme Brad King (17): Intel: Fix default C++ dialect detection on Windows Tests: Update CompileFeatures test for Intel 19 with VS 2015 Help: Document CMAKE_UNITY_BUILD in 3.16 release notes Help: Improve UNITY_BUILD documentation formatting Help: Extend documentation of CMAKE_UNITY_BUILD variable Help: Document CMAKE_UNITY_BUILD/CMAKE_EXPORT_COMPILE_COMMANDS limitation VS: Add toolset v142 CSharp flag table IRSL: Prefer MSVC runtime libraries from newest toolset first IRSL: Install vcruntime140_1.dll if available CMakeVersion: Prefer Git information provided by 'git archive' exports Help: Clarify documentation of CMAKE_STATIC_LINKER_FLAGS CMakeFindBinUtils: Remove unnecessary variable unset calls PCH: Document and test COMPILE_LANGUAGE genex for per-language header install,export: Do not treat language names as target names cmMakefileTargetGenerator: Inline WriteObjectBuildFile in only call site PCH: Fix Makefile dependencies to rebuild PCH on header changes CMake 3.16.0-rc2 Cristian Adam (1): Objective-C: Do not treat Objective-C files as C++ files Konstantin Pyzhov (1): FindOpenMP: Add support for HIP clang device pass Kyle Edwards (1): CMakeVersion: Add option to disable Git suffix Manuel Herrmann (1): FindCurses: use tinfow when wide support is requested Micael Borgefeldt (2): IAR: Fix v850 assembler support file extensions IAR: Add 8051 support Peter Waller (1): cmake: Fix relative path regression in -C Saleem Abdulrasool (1): try_compile: support Swift for cross-compilation Tom Lankhorst (1): Help: Fix typos and style in add_link_options documentation Willem Deconinck (2): FindHDF5: Cray HDF5 Fortran module filename is usually capitalized FindHDF5: Append hdf5 to hdf5_hl to avoid undefined references From wouter.klouwen at youview.com Mon Oct 21 08:35:40 2019 From: wouter.klouwen at youview.com (Wouter Klouwen) Date: Mon, 21 Oct 2019 12:35:40 +0000 Subject: [cmake-developers] CTest load balancing In-Reply-To: References: Message-ID: <4daddbd4-d72b-82ca-8624-988e6612bcd7@youview.com> On 16/10/2019 15:10, Brad King wrote: > On 10/16/19 10:05 AM, Wouter Klouwen wrote: >> Is the intent for CTest to specifically manage CPU load or system load >> overall? > > I don't think a careful distinction was made at the time. > > If Linux needs some updates to be consistent with other platforms > then that would be fine with me. Unfortunately this may be easier said than done. Most of the data relevant to this lives in /proc. Indeed the getloadavg() implementation of glibc merely reads /proc/loadavg*. For load average the scheduler keeps track of the running 1, 5, 15 minute running averages. There's /proc/stat which keeps a running total of the CPU usage - the first lines beginning with `cpu` - but for the purposes of this it is in the format of usage since boot. In order to replicate a CPU utilisation only load, you'd effectively have to pick a point in time to start and then measure since the reference point, which makes things a bit complicated. From the same file you could also take the lines `procs_running` and `procs_blocked`, sum them and present them as a pseudo load. It would be a fairly robust calculation. I don't know if this would be quite correct though. I might just create an issue for this. W *: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getloadavg.c;hb=HEAD th > > -Brad > > > [External email. Treat hyperlinks and attachments with caution] > This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com From Alan.W.Irwin1234 at gmail.com Thu Oct 24 00:18:40 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Wed, 23 Oct 2019 21:18:40 -0700 (PDT) Subject: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug? Message-ID: Hi Brad: The two generator expressions $<$:-pthread> and $<$,$>:-pthread> are supposed to be equivalent according to the cmake-generator-expressions manual. Up to now I have always used the first form when setting the INTERFACE_LINK_OPTIONS property of an interface library which my D examples link with. All my tests of that form for both the test_d and plplot cases work fine. So I was about to declare that my D language support (a fork of the cmake-d project which I hope to merge back with that project) was perfect for our needs (at least on Linux) until I ran into a problem with the above second generator expression which I will now describe. Some old versions (e.g., 3.13.2) of CMake that PLplot still needs to support do not implement the $ generator expression so after the first form passed all tests, I tried switching to the second generator expression for the plplot case. However, that generated errors at CMake time which are typically (for each of our D examples) CMake Error at examples/d/CMakeLists.txt:119 (target_link_libraries): Error evaluating generator expression: $ Expression did not evaluate to a known generator expression [...] -- Generating done CMake Generate step failed. Build files cannot be regenerated correctly. These errors were obtained with cmake version 3.15.20190829-g3ec986c (the version I have recently been using for testing). This is a really peculiar result since both forms provide the same information (language and compiler id) and are supposed to be equivalent, i.e., both forms should either work or not work. And the second form works for the Fortran case (where I am having to deal with a similar -pthread issue). So my guess is there is some internal implementation issue with the second form that makes it not quite equivalent to the first form, and some minor issue with my D language support (that otherwise works perfectly for PLplot needs on Linux) has exposed this implementation difference. If you confirm that guess, then ideally the CMake implementation should be changed so the second form is equivalent to the first form in all circumstances. And I would be happy to test that change with my present CMake D language support. I also need the second form of generator expression to work with older unfixed CMake versions so once you spot the implementation difference between the two forms I would also appreciate a hint about how to change my CMake D language support so the present CMake code does not generate the above type of errors for the second form of the generator expression. In case you need details about my present CMake D language support, those can be found at either cmake/test_d/cmake/Modules or cmake/modules/language_support/cmake-d_fork/ within the plplot source tree. That source tree can be cloned using git clone https://git.code.sf.net/p/plplot/plplot plplot.git Alan __________________________ Alan W. Irwin 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.org); 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 Thu Oct 24 08:08:40 2019 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Oct 2019 08:08:40 -0400 Subject: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug? In-Reply-To: References: Message-ID: <0a390c05-5bdd-b358-6444-a9915d0936da@kitware.com> On 10/24/19 12:18 AM, Alan W. Irwin wrote: > $ > > Expression did not evaluate to a known generator expression The `*_COMPILER_ID` generator expressions are a hard-coded set corresponding to the languages supported by upstream CMake: * C_COMPILER_ID * CXX_COMPILER_ID * CUDA_COMPILER_ID * Fortran_COMPILER_ID * OBJC_COMPILER_ID (new in 3.16) * OBJCXX_COMPILER_ID (new in 3.16) This is because the language name is part of the expression name. In the `$` case, the language name is one of the parameters. -Brad From Alan.W.Irwin1234 at gmail.com Thu Oct 24 15:41:15 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 24 Oct 2019 12:41:15 -0700 (PDT) Subject: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug? In-Reply-To: <0a390c05-5bdd-b358-6444-a9915d0936da@kitware.com> References: <0a390c05-5bdd-b358-6444-a9915d0936da@kitware.com> Message-ID: On 2019-10-24 08:08-0400 Brad King wrote: > On 10/24/19 12:18 AM, Alan W. Irwin wrote: >> $ >> >> Expression did not evaluate to a known generator expression > > The `*_COMPILER_ID` generator expressions are a hard-coded set > corresponding to the languages supported by upstream CMake: > > * C_COMPILER_ID > * CXX_COMPILER_ID > * CUDA_COMPILER_ID > * Fortran_COMPILER_ID > * OBJC_COMPILER_ID (new in 3.16) > * OBJCXX_COMPILER_ID (new in 3.16) > > This is because the language name is part of the expression name. > > In the `$` case, the language name > is one of the parameters. Thanks for that clear explanation of this current CMake hard-coded limitation. To work around it, I will stick with the $ genex, but only bother with that -pthread mapping for cmake 3.15.0 and above (since that is the first version of CMake to support $). So that takes care of PLplot's needs. However, on the general question of the above CMake hard-coded language limitation I searched through for "CXX" and found these genex's $<"language"_COMPILER_ID:compiler_ids> $<"language"_COMPILER_VERSION:version> $<"language"_COMPILER_ID> $<"language"_COMPILER_VERSION> where I have substituted "language" for CXX to indicate these actually represent 4 different classes of genex's where "language" is currently on a hard-coded list for the first, and it appears from Source/cmGeneratorExpressionNode.cxx that is true of the rest as well. My C++ skills are limited and as a result I don't understand the CMake code that well, and I don't have any idea how difficult this would be to implement. So I should ask would you entertain a feature request to remove that hard-coded language limitation on the above 4 classes of genex so both internally and externally supported languages would work for all of them? For example, you currently have $<"language"_COMPILER_ID:compiler_ids> where compiler_ids is a comma-separated list. 1 if the CMake?s compiler id of the "language" compiler matches any one of the entries in compiler_ids, otherwise 0. See also the CMAKE__COMPILER_ID variable where "language" is restricted to the above hard-coded list. Would it be straightforward to change the implementation of this whole class of genexes so that "language" was simply determined from the first part of the genex name with that "language" then checked against the available language support? If so, that approach would solve the above issue (i.e., drop this artificial distinction between languages with internal and external support) and also have the additional advantages that it would replace what I presume are currently 6 different genex implementations and the documentation of each of those with just one implementation and corresponding piece of documentation with no introduced backwards incompatibilities due to this change. And similarly for $<"language"_COMPILER_VERSION:version> $<"language"_COMPILER_ID> $<"language"_COMPILER_VERSION> Alan __________________________ Alan W. Irwin 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.org); 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 gjasny at googlemail.com Sat Oct 26 13:31:22 2019 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 26 Oct 2019 19:31:22 +0200 Subject: [cmake-developers] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing In-Reply-To: References: Message-ID: <10254b8b-7c02-5e19-d660-daa70228f1ff@googlemail.com> Hello, On 20.10.19 19:25, Robert Maynard via cmake-developers wrote: > I am proud to announce the second CMake 3.16 release candidate. > https://cmake.org/download/ CMake 3.16.0-rc2 successfully builds and tests our two large mono-repos. I'm looking forward to the release! Thanks, Gregor From roman.wueger at gmx.at Mon Oct 28 16:36:57 2019 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 28 Oct 2019 21:36:57 +0100 Subject: [cmake-developers] productbuild: Installing to absolute system path or to user home path Message-ID: ? Hello, I tried to install a file/directory with productbuild on macOS which is generated with CPack. The most of the files are installed correctly, but I have two problems: If I want to install to ?/Library/Application\ Support/Adobe/Lightroom/Modules? If I want to install to the users modules folder ?~/Library/Application\ Support/Adobe/Lightroom/Modules? How can I archive these two? I already tried the following with no luck: install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin DESTINATION /Library/Application\ Support/Adobe/Lightroom/Modules) install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin DESTINATION ~/Library/Application\ Support/Adobe/Lightroom/Modules) Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.despres at gmail.com Tue Oct 29 09:57:30 2019 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Tue, 29 Oct 2019 14:57:30 +0100 Subject: [cmake-developers] generator expression in install RENAME Message-ID: Hi there, Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part of an install command. Would that be possible to enable generator expression in the RENAME part as well? The use-case is for the TARGET_FILE_BASE_NAME expression. Cheers, -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Oct 29 11:30:07 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 29 Oct 2019 11:30:07 -0400 Subject: [cmake-developers] generator expression in install RENAME In-Reply-To: References: Message-ID: Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues to request support for this. Kyle On Tue, Oct 29, 2019 at 9:58 AM Nicolas Despr?s wrote: > > Hi there, > > Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part of an install command. > > Would that be possible to enable generator expression in the RENAME part as well? > > The use-case is for the TARGET_FILE_BASE_NAME expression. > > Cheers, > > -- > Nicolas Despr?s > > -- > > 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 From Alan.W.Irwin1234 at gmail.com Tue Oct 29 15:07:53 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 29 Oct 2019 12:07:53 -0700 (PDT) Subject: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug? In-Reply-To: References: <0a390c05-5bdd-b358-6444-a9915d0936da@kitware.com> Message-ID: On 2019-10-24 12:41-0700 Alan W. Irwin wrote: > [.... W]ould you entertain a feature request to remove > that > hard-coded language limitation on the above 4 classes of genex so both > internally and externally supported languages would work for all of > them? Well, since you did not respond I assume you are at least not horrified by that idea so I have written this up as and further discussion should appear there. Alan __________________________ Alan W. Irwin 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.org); 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 robert.maynard at kitware.com Wed Oct 30 14:55:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 30 Oct 2019 14:55:00 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.15.5 available for download Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.despres at gmail.com Thu Oct 31 06:34:25 2019 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Thu, 31 Oct 2019 11:34:25 +0100 Subject: [cmake-developers] generator expression in install RENAME In-Reply-To: References: Message-ID: Done: https://gitlab.kitware.com/cmake/cmake/issues/19903 On Tue, Oct 29, 2019 at 4:30 PM Kyle Edwards wrote: > Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues > to request support for this. > > Kyle > > On Tue, Oct 29, 2019 at 9:58 AM Nicolas Despr?s > wrote: > > > > Hi there, > > > > Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION > part of an install command. > > > > Would that be possible to enable generator expression in the RENAME part > as well? > > > > The use-case is for the TARGET_FILE_BASE_NAME expression. > > > > Cheers, > > > > -- > > Nicolas Despr?s > > > > -- > > > > 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 > -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Oct 31 13:05:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 31 Oct 2019 13:05:00 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.16.0-rc3 is ready for testing Message-ID: 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 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). Command-Line ------------ * "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. Commands -------- * The "add_test()" command learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * 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". * 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 "find_package()" command has learned to check the following variables to control searching * "CMAKE_FIND_USE_PACKAGE_REGISTRY" - Controls the searching the cmake user registry. * The "message()" command learned indentation control with the new "CMAKE_MESSAGE_INDENT" variable. * The "target_precompile_headers()" command was added to specify a list of headers to precompile for faster compilation times. Variables --------- * The "CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS" variable has been introduced to optionally initialize the "CUDA_RESOLVE_DEVICE_SYMBOLS" target property. * The "CMAKE_ECLIPSE_RESOURCE_ENCODING" variable was added to specify the resource encoding for the the "Eclipse CDT4" extra generator. Properties ---------- * The "BUILD_RPATH" and "INSTALL_RPATH" target properties now support "generator expressions". * The "INSTALL_REMOVE_ENVIRONMENT_RPATH" target property was added to remove compiler-defined "RPATH" entries from a target. This property is initialized by the "CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH" variable. * The "PRECOMPILE_HEADERS" target property was added to specify a list of headers to precompile for faster compilation times. Set it using the "target_precompile_headers()" command. * The "UNITY_BUILD" target property was added to tell generators to batch include source files for faster compilation times. * The "VS_CONFIGURATION_TYPE" target property now supports "generator expressions". * The "VS_DPI_AWARE" target property was added to tell Visual Studio Generators to set the "EnableDpiAwareness" property in ".vcxproj" files. * The "XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING" target property was added to tell the "Xcode" generator to set the value of the "Allow debugging when using document Versions Browser" schema option. Modules ------- * The "FindDoxygen" module "doxygen_add_docs()" command gained a new "USE_STAMP_FILE" option. When this option present, the custom target created by the command will only re-run Doxygen if any of the source files have changed since the last successful run. * The "FindGnuTLS" module now provides an imported target. * The "FindPackageHandleStandardArgs" module "find_package_handle_standard_args()" command gained a new "REASON_FAILURE_MESSAGE" option to specify a message giving the reason for the failure. * The "FindPkgConfig" module "pkg_search_module()" macro now defines a "_MODULE_NAME" result variable containing the first matching module name. * The "FindPython3" and "FindPython" modules gained options to control which "ABIs" will be searched. * The "FindPython3", "FindPython2", and "FindPython" modules now support direct specification of artifacts via cache entries. Autogen ------- * When using "AUTOMOC", CMake now generates the "-p" path prefix option for "moc". This ensures that "moc" output files are identical on different build setups (given, that the headers compiled by "moc" are in an "include directory"). Also it ensures that "moc" output files will compile correctly when the source and/or build directory is a symbolic link. The "moc" path prefix generation behavior can be configured by setting the new "CMAKE_AUTOMOC_PATH_PREFIX" variable and/or "AUTOMOC_PATH_PREFIX" target property. CTest ----- * "ctest(1)" now has the ability to serialize tests based on hardware requirements for each test. See Hardware Allocation for details. * A new test property, "SKIP_REGULAR_EXPRESSION", has been added. This property is similar to "FAIL_REGULAR_EXPRESSION" and "PASS_REGULAR_EXPRESSION", but with the same meaning as "SKIP_RETURN_CODE". This is useful, for example, in cases where the user has no control over the return code of the test. For example, in Catch2, the return value is the number of assertion failed, therefore it is impossible to use it for "SKIP_RETURN_CODE". CPack ----- * CPack variable "CPACK_INSTALL_CMAKE_CONFIGURATIONS" was added to control what configurations are to be packaged for multi- configuration CMake generators. * The "CPack DEB Generator" is now able to format generic text (usually used as the description for multiple CPack generators) according to the Debian Policy Manual. See the "CPACK_PACKAGE_DESCRIPTION_FILE" and "CPACK_DEBIAN__DESCRIPTION" variables. * The "CPack Archive Generator" learned to generate ".tar.zst" packages with Zstandard compression. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policy "CMP0067" ("CMP0066" 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 "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)". * The "CPACK_INSTALL_SCRIPT" variable has been deprecated in favor of the new, more accurately named "CPACK_INSTALL_SCRIPTS" variable. Other Changes ============= * The "cmake(1)" "-C " option now evaluates the initial cache script with "CMAKE_SOURCE_DIR" and "CMAKE_BINARY_DIR" set to the top-level source and build trees. * The "cmake(1)" "-E remove_directory" command-line tool, when given the path to a symlink to a directory, now removes just the symlink. It no longer removes content of the linked directory. * The "ctest(1)" "--build-makeprogram" command-line option now specifies the make program used when configuring a project with the "Ninja" generator or the Makefile Generators. * The "ExternalProject" module "ExternalProject_Add()" command has been updated so that "GIT_SUBMODULES """ initializes no submodules. See policy "CMP0097". * The "FindGTest" module has been updated to recognize MSVC build trees generated 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-rc2: Alan W. Irwin (1): Help: Fix COMPILE_LANG_AND_ID genex example Brad King (3): Swift: Honor CMAKE_OSX_SYSROOT on Apple platforms bootstrap: Avoid redundant compiler selection checks CMake 3.16.0-rc3 Craig Scott (9): FindOpenMP: Allow try_compile() to find omp.h for AppleClang Help: math() expressions must be representable as signed 64-bit project: Fix potential buffer write-past-end for version components Help: Document that _ROOT applies to config packages too Help: Fix markup errors, improve wording of CMAKE_FIND... variable docs Help: Minor wording cleanup for Python modules Tests: Prevent CMP0012 policy warnings in Framework test output Tests: Match file command output for older macOS (Framework test) Help: Fix minor typo in CMakePrintHelpers module docs Deniz Bahadir (1): Help: Add OPTIONAL_COMPONENTS to config mode signature of find_package. Kyle Edwards (1): Help: Fix capitalization in CMP0097 documentation Marc Chevrier (1): Help: Fix spelling error in file(GET_RUNTIME_DEPENDENCIES) docs Saleem Abdulrasool (2): Swift: correct flags for parallel jobs Swift: support `BUILD_RPATH` properties Sebastian Holtermann (1): Autogen: Fix ambiguity in header file detection on Windows Sylvain Joubert (1): ccmake: Fully clear the 1st help line when processing nick black (1): FindCurses: use formw when wide support is requested From DLRdave at aol.com Thu Oct 31 13:18:44 2019 From: DLRdave at aol.com (David Cole) Date: Thu, 31 Oct 2019 13:18:44 -0400 Subject: [cmake-developers] productbuild: Installing to absolute system path or to user home path In-Reply-To: References: Message-ID: According to the docs, the INSTALL command uses the absolute path if it is given as the DESTINATION, so .... it should work. https://cmake.org/cmake/help/latest/command/install.html Did you try using a double quoted string, instead of escaping the space with a backslash? I think this should work for the absolute one: INSTALL( ... DESTINATION "/abs/path/to/some folder") For the one in the home directory, I'm not sure if a string that starts with "~" is considered absolute or not, so it may or may not end up where you expect it. Can you resolve it before hand with a get_filename_component call, (or otherwise), and pass in a string that begins with "/" ...? Hope this helps, David C. On Mon, Oct 28, 2019 at 4:36 PM Roman W?ger wrote: > > ? > > Hello, > > > > I tried to install a file/directory with productbuild on macOS which is generated with CPack > > The most of the files are installed correctly, but I have two problems: > > > > If I want to install to ?/Library/Application\ Support/Adobe/Lightroom/Modules? > If I want to install to the users modules folder ?~/Library/Application\ Support/Adobe/Lightroom/Modules? > > > > How can I archive these two? > > > > I already tried the following with no luck: > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION /Library/Application\ Support/Adobe/Lightroom/Modules) > > > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION ~/Library/Application\ Support/Adobe/Lightroom/Modules) > > > > Best Regards > > Roman > > -- > > 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 From DLRdave at aol.com Thu Oct 31 13:18:44 2019 From: DLRdave at aol.com (David Cole) Date: Thu, 31 Oct 2019 13:18:44 -0400 Subject: [cmake-developers] productbuild: Installing to absolute system path or to user home path In-Reply-To: References: Message-ID: According to the docs, the INSTALL command uses the absolute path if it is given as the DESTINATION, so .... it should work. https://cmake.org/cmake/help/latest/command/install.html Did you try using a double quoted string, instead of escaping the space with a backslash? I think this should work for the absolute one: INSTALL( ... DESTINATION "/abs/path/to/some folder") For the one in the home directory, I'm not sure if a string that starts with "~" is considered absolute or not, so it may or may not end up where you expect it. Can you resolve it before hand with a get_filename_component call, (or otherwise), and pass in a string that begins with "/" ...? Hope this helps, David C. On Mon, Oct 28, 2019 at 4:36 PM Roman W?ger wrote: > > ? > > Hello, > > > > I tried to install a file/directory with productbuild on macOS which is generated with CPack > > The most of the files are installed correctly, but I have two problems: > > > > If I want to install to ?/Library/Application\ Support/Adobe/Lightroom/Modules? > If I want to install to the users modules folder ?~/Library/Application\ Support/Adobe/Lightroom/Modules? > > > > How can I archive these two? > > > > I already tried the following with no luck: > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION /Library/Application\ Support/Adobe/Lightroom/Modules) > > > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION ~/Library/Application\ Support/Adobe/Lightroom/Modules) > > > > Best Regards > > Roman > > -- > > 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 From DLRdave at aol.com Thu Oct 31 13:18:44 2019 From: DLRdave at aol.com (David Cole) Date: Thu, 31 Oct 2019 13:18:44 -0400 Subject: [cmake-developers] productbuild: Installing to absolute system path or to user home path In-Reply-To: References: Message-ID: According to the docs, the INSTALL command uses the absolute path if it is given as the DESTINATION, so .... it should work. https://cmake.org/cmake/help/latest/command/install.html Did you try using a double quoted string, instead of escaping the space with a backslash? I think this should work for the absolute one: INSTALL( ... DESTINATION "/abs/path/to/some folder") For the one in the home directory, I'm not sure if a string that starts with "~" is considered absolute or not, so it may or may not end up where you expect it. Can you resolve it before hand with a get_filename_component call, (or otherwise), and pass in a string that begins with "/" ...? Hope this helps, David C. On Mon, Oct 28, 2019 at 4:36 PM Roman W?ger wrote: > > ? > > Hello, > > > > I tried to install a file/directory with productbuild on macOS which is generated with CPack > > The most of the files are installed correctly, but I have two problems: > > > > If I want to install to ?/Library/Application\ Support/Adobe/Lightroom/Modules? > If I want to install to the users modules folder ?~/Library/Application\ Support/Adobe/Lightroom/Modules? > > > > How can I archive these two? > > > > I already tried the following with no luck: > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION /Library/Application\ Support/Adobe/Lightroom/Modules) > > > > install(DIRECTORY $/${CMAKE_PROJECT_NAME}.lrplugin > > DESTINATION ~/Library/Application\ Support/Adobe/Lightroom/Modules) > > > > Best Regards > > Roman > > -- > > 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