From jimmy at dcode.eu Mon Feb 3 04:31:14 2020 From: jimmy at dcode.eu (De Pauw jimmy) Date: Mon, 3 Feb 2020 10:31:14 +0100 Subject: [CMake] cross-compiling final linker transitive lib not found Message-ID: <401bf089-65df-8307-2e19-b94ebf1a8ee4@dcode.eu> Hello, I have a problem with cross-compiling that i don't know how to solve even after days of searching. The situation is : - Project compiled on ARM platform directly, works fine. - Cross-compiled, final executable linking fails because of a transitive library not found. I am using a few system libraries that are all found in the initial cmake setup. Compiling also works until it requires linking of my final target. There, at some point, it checks for /usr/local/sysroot_jetson/usr/lib/aarch64-linux-gnu/libdrm.so.2 (which is found) libdrm depends on libnvll.so wich the linker does not found even though it's available on my sysroot but not in a standard directory. The directory is /usr/local/sysroot_jetson/usr/lib/aarch64-linux-gnu/tegra On the ARM system this directory is searched by the linker because of /etc/ld.so.conf.d/cuda-10-0.conf but this is not used at all when cross-compiling. How the linker when cross-compiling can be instructed to search in additional directories for transitive dependencies? From jedrzej.dudkiewicz at gmail.com Mon Feb 3 14:48:50 2020 From: jedrzej.dudkiewicz at gmail.com (=?UTF-8?Q?J=C4=99drzej_Dudkiewicz?=) Date: Mon, 3 Feb 2020 20:48:50 +0100 Subject: [CMake] crosscompilation and source generation via add_custom_command Message-ID: Hello, I cross-compile a project from x86_64-linux-gnu to arm-linux-gnueabihf. Currently this is done using hand-written Makefiles, but I"m moving it to cmake. This project uses custom version of `lemon` parser generator. Aforementioned lemon is included as a source - this is single .c file that is compiled during build. Is there a way to build and run this binary on x86_64-linux-gnu while cross-compiling to arm-linux-gnuabihf? I suppose I could add_custom_command that would compile using hardcoded compiler version, but it doesn't seem very nice. Thanks in advance, -- J?drzej Dudkiewicz I really hate this damn machine, I wish that they would sell it. It never does just what I want, but only what I tell it. From post at hendrik-sattler.de Mon Feb 3 15:11:41 2020 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 03 Feb 2020 21:11:41 +0100 Subject: [CMake] crosscompilation and source generation via add_custom_command In-Reply-To: References: Message-ID: Am 3. Februar 2020 20:48:50 MEZ schrieb "J?drzej Dudkiewicz" : >Hello, > >I cross-compile a project from x86_64-linux-gnu to >arm-linux-gnueabihf. Currently this is done using hand-written >Makefiles, but I"m moving it to cmake. This project uses custom >version of `lemon` parser generator. Aforementioned lemon is included >as a source - this is single .c file that is compiled during build. Is >there a way to build and run this binary on x86_64-linux-gnu while >cross-compiling to arm-linux-gnuabihf? I suppose I could >add_custom_command that would compile using hardcoded compiler >version, but it doesn't seem very nice. You can compile the tool using ExternalProject. This needs a separate directory with a its own CMakeLists.txt file for the tool. >Thanks in advance, >-- >J?drzej Dudkiewicz > >I really hate this damn machine, I wish that they would sell it. >It never does just what I want, but only what I tell it. >-- > >Powered by kitware.com/cmake > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit >https://cmake.org/services > >Visit other Kitware open-source projects at >https://www.kitware.com/platforms > >Follow this link to subscribe/unsubscribe: >https://cmake.org/mailman/listinfo/cmake > >This mailing list is deprecated in favor of https://discourse.cmake.org From jedrzej.dudkiewicz at gmail.com Mon Feb 3 16:20:16 2020 From: jedrzej.dudkiewicz at gmail.com (=?UTF-8?Q?J=C4=99drzej_Dudkiewicz?=) Date: Mon, 3 Feb 2020 22:20:16 +0100 Subject: [CMake] crosscompilation and source generation via add_custom_command In-Reply-To: References: Message-ID: On Mon, Feb 3, 2020 at 9:22 PM Hendrik Sattler wrote: > Am 3. Februar 2020 20:48:50 MEZ schrieb "J?drzej Dudkiewicz" : > >Hello, > > > >I cross-compile a project from x86_64-linux-gnu to > >arm-linux-gnueabihf. Currently this is done using hand-written > >Makefiles, but I"m moving it to cmake. This project uses custom > >version of `lemon` parser generator. Aforementioned lemon is included > >as a source - this is single .c file that is compiled during build. Is > >there a way to build and run this binary on x86_64-linux-gnu while > >cross-compiling to arm-linux-gnuabihf? I suppose I could > >add_custom_command that would compile using hardcoded compiler > >version, but it doesn't seem very nice. > > You can compile the tool using ExternalProject. This needs a separate directory with a its own CMakeLists.txt file for the tool. Thank you, I will look into it, although I'm not sure if this isn't a massive overkill in my case. Thanks! -- J?drzej Dudkiewicz I really hate this damn machine, I wish that they would sell it. It never does just what I want, but only what I tell it. From robert.maynard at kitware.com Tue Feb 4 10:57:59 2020 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 4 Feb 2020 10:57:59 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.15.7 available for download Message-ID: We are pleased to announce that CMake 3.15.7 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.15.7 since 3.15.6: Brad King (4): IRSL: Install msvcp140_{1,2,codecvt_ids}.dll if available ASM_MASM: Populate MSVC runtime library abstraction table VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs CMake 3.15.7 Robert Maynard (1): CUDA: Do not device link if target has no CUDA usage From robert.maynard at kitware.com Wed Feb 5 12:47:57 2020 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 5 Feb 2020 12:47:57 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.16.4 available for download Message-ID: We are pleased to announce that CMake 3.16.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.16.4 since 3.16.3: Brad King (6): ASM_MASM: Populate MSVC runtime library abstraction table VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs AIX: Restore pre-3.16 undocumented method to suppress exports with XL Android: Fix binutils selection with NDK r19+ unified toolchain VS: Do not use native unity builds on VS 2017 versions less than 15.8 CMake 3.16.4 Kyle Edwards (3): file(GET_RUNTIME_DEPENDENCIES): Tolerate empty list arguments Help: Add more variable documentation to FindMPI CPack: Fix regression in Deb description From michael at scivision.dev Thu Feb 6 22:49:48 2020 From: michael at scivision.dev (Michael Hirsch, Ph.D.) Date: Thu, 6 Feb 2020 22:49:48 -0500 Subject: [CMake] Intel ifort Windows cmake_fortran_flags: bug or user error? Message-ID: I typically "set(CMAKE_Fortran_FLAGS ...)" variable in my CMake project to set compile flags for all Fortran targets. Is this undesired practice? I haven't had any problems using multiple compilers, *except* for Intel Ifort on Windows. Ifort on Linux is fine. Here are the flags that CMake auto-sets for Ifort Windows in CMAKE_Fortran_FLAGS: "/W1 /nologo /fpp /libs:dll" The flag my project needs and that CMake auto-sets is "/libs:dll" I can workaround this issue by just appending those flags to my flags in CMAKE_Fortran_FLAGS. * should I not be setting CMAKE_Fortran_FLAGS manually? * Is this a CMake "bug" for Ifort on Windows? * CMake with Ifort on Linux also auto-sets compiler flags like "-fpp" but doesn't put them in CMAKE_Fortran_FLAGS. From dustyn at blasig.us Fri Feb 7 21:54:07 2020 From: dustyn at blasig.us (Dustyn Blasig) Date: Fri, 7 Feb 2020 20:54:07 -0600 Subject: [CMake] CUDA aarch64 cross compile fails to validate nvcc Message-ID: Hi All, I'm not sure if people are more active on here or Discourse right now, so I'm cross-posting. Please reply on the Discourse thread if possible, but I'll take whatever I can get : ) https://discourse.cmake.org/t/cuda-aarch64-cross-compile-fails-to-validate-nvcc/593 I am stuck trying to make all the CMake pieces happy with the cross-compile, everything I try makes some part of the flow fail, either missing flags or tools not be setup properly. Any help much appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Mon Feb 10 07:49:05 2020 From: hex7c3 at gmail.com (hex) Date: Mon, 10 Feb 2020 12:49:05 +0000 Subject: [CMake] build step is not thread-safe for CMake Message-ID: hello, My build step is not thread-safe (the instruction in the COMMAND part). Every build step depends on one source file: /add_custom_command(// //??????? DEPENDS on_source.file// //??????? OUTPUT// //??????????????? object_file_for_source_file// //??????? COMMAND not-thread-safe-compiler --build on_source.file// //??????? COMMENT// //??????? ? ?? ?? "Building Source object"// //)/ add_custom_target DEPENDS on OUTPUT from all custom command's, but in order to prevent parallel execution when cmake is called: /cmake --build . --target all -j30/ I need to build each step in any order, but still not as a dependency as this would trigger unnecessary recompilation. Using MAIN_DEPENDENCY defines hierarchical dependency, but this won't help in this situation. I cannot figure out how to prevent parallel execution of COMMAND in CMake. The only option I see is a single command /add_custom_target(tgt// //??????? DEPENDS on_all_source.files// //??????? COMMAND not-thread-safe-compiler --build on_source1.file/ /??????? COMMAND not-thread-safe-compiler --build on_source2.file/ /??????? COMMAND not-thread-safe-compiler --build on_source3.file/ /??????? . . .// / /??????? COMMENT// //??????? ? ?? ?? "Building target"// //)/ this would rebuild every source, though. How do I set this up? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Mon Feb 10 08:23:48 2020 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 10 Feb 2020 08:23:48 -0500 Subject: [CMake] build step is not thread-safe for CMake In-Reply-To: References: Message-ID: <1581341028.31213.1.camel@kitware.com> On Mon, 2020-02-10 at 12:49 +0000, hex wrote: > hello, > > My build step is not thread-safe (the instruction in the COMMAND > part). Every build step depends on one source file: > > add_custom_command( > ??????? DEPENDS on_source.file > ??????? OUTPUT > ??????????????? object_file_for_source_file > ??????? COMMAND not-thread-safe-compiler --build on_source.file > ??????? COMMENT > ??????? ? ?? ?? "Building Source object" > ) > > add_custom_target DEPENDS on OUTPUT from all custom command's, but in > order to prevent parallel execution when cmake is called: > > cmake --build . --target all -j30 > > I need to build each step in any order, but still not as a dependency > as this would trigger unnecessary recompilation. Using > MAIN_DEPENDENCY defines hierarchical dependency, but this won't help > in this situation. > > I cannot figure out how to prevent parallel execution of COMMAND in > CMake. The only option I see is a single command > > add_custom_target(tgt > ??????? DEPENDS on_all_source.files > ??????? COMMAND not-thread-safe-compiler --build on_source1.file > ??????? COMMAND not-thread-safe-compiler --build on_source2.file > ??????? COMMAND not-thread-safe-compiler --build on_source3.file > ??????? . . . > ??????? COMMENT > ??????? ? ?? ?? "Building target" > ) > > this would rebuild every source, though. > > How do I set this up? > > thank you It sounds like you want order-only dependencies: dependencies the command waits for before building, but whose changes do not actually trigger a rebuild. As far as I know, add_custom_command() doesn't have support for this - perhaps it could be added. This mailing list is deprecated. Please move further discussion to the Discourse forum: https://discourse.cmake.org/c/code/11 Kyle From kwilliams at leepfrog.com Mon Feb 10 17:12:32 2020 From: kwilliams at leepfrog.com (Kent Williams) Date: Mon, 10 Feb 2020 16:12:32 -0600 Subject: [CMake] FindICU.cmake setting ICU_FOUND to "FALSE" with quotes? Message-ID: <25a4fc12-da5a-2ef7-8d6c-eca36bb68390@leepfrog.com> I was trying to do this: > find_package(ICU 59.1 QUIET > COMPONENTS > data > i18n > io > tu > uc > ) > if(ICU_FOUND) > ? include_directories(BEFORE ${ICU_INCLUDE_DIRS}) > ? message("ICU_LIBRARIES=${ICU_LIBRARIES}") > endif() And at configuration time, ICU_FOUND was turning up with double quotes around it, and as we all know from CMake 101, the string "FALSE" has a truth value of TRUE in the if statement. This is with cmake 3.16. I fixed this by changing the expression to IF(ICU_FOUND AND NOT "${ICU_FOUND}" STREQUAL "\"FALSE\"") but that doesn't seem right somehow! From doenges at mvtec.com Tue Feb 11 06:48:12 2020 From: doenges at mvtec.com (Eric Doenges) Date: Tue, 11 Feb 2020 12:48:12 +0100 Subject: [CMake] build step is not thread-safe for CMake In-Reply-To: <1581341028.31213.1.camel@kitware.com> References: <1581341028.31213.1.camel@kitware.com> Message-ID: <0efbf577-59ba-0c33-4bc8-6d07dbee8291@mvtec.com> Am 10.02.20 um 14:23 schrieb Kyle Edwards via CMake: > On Mon, 2020-02-10 at 12:49 +0000, hex wrote: >> hello, >> >> My build step is not thread-safe (the instruction in the COMMAND >> part). Every build step depends on one source file: >> >> add_custom_command( >> ??????? DEPENDS on_source.file >> ??????? OUTPUT >> ??????????????? object_file_for_source_file >> ??????? COMMAND not-thread-safe-compiler --build on_source.file >> ??????? COMMENT >> ??????? ? ?? ?? "Building Source object" >> ) >> >> add_custom_target DEPENDS on OUTPUT from all custom command's, but in >> order to prevent parallel execution when cmake is called: >> >> cmake --build . --target all -j30 >> >> I need to build each step in any order, but still not as a dependency >> as this would trigger unnecessary recompilation. Using >> MAIN_DEPENDENCY defines hierarchical dependency, but this won't help >> in this situation. >> >> I cannot figure out how to prevent parallel execution of COMMAND in >> CMake. The only option I see is a single command >> >> add_custom_target(tgt >> ??????? DEPENDS on_all_source.files >> ??????? COMMAND not-thread-safe-compiler --build on_source1.file >> ??????? COMMAND not-thread-safe-compiler --build on_source2.file >> ??????? COMMAND not-thread-safe-compiler --build on_source3.file >> ??????? . . . >> ??????? COMMENT >> ??????? ? ?? ?? "Building target" >> ) >> >> this would rebuild every source, though. >> >> How do I set this up? >> >> thank you > It sounds like you want order-only dependencies: dependencies the > command waits for before building, but whose changes do not actually > trigger a rebuild. As far as I know, add_custom_command() doesn't have > support for this - perhaps it could be added. Actually, I think it kind of does, at least with the Ninja generator. If you do something like add_custom_output(OUTPUT fileA COMMAND ...) add_custom_target(fileA_target DEPENDS fileA) add_custom_output(OUTPUT fileB DEPENDS fileA COMMAND ...) add_custom_output(OUTPUT fileC DEPENDS fileA_target COMMAND ...) then both fileB and fileC will depend on fileA existing, but fileC will not be rebuilt if fileA changes, while fileB will be. Disclaimer - I couldn't find this behavior described in the documentation, but it is what I've observed after spending extensive amounts of time messing about with add_custom_command() and add_custom_target() to build the documentation to our product with CMake 3.16. Also, I've only tested this with the Ninja generator, so it may behave differently with other generators. With kind regards, Eric D?nges *Dr. Eric D?nges* Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Find our privacy policy here . Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Feb 12 14:12:02 2020 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Feb 2020 14:12:02 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.17.0-rc1 is ready for testing Message-ID: I am proud to announce the first CMake 3.17 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.17 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.17/release/3.17.html Some of the more significant changes in CMake 3.17 are: * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL?s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead it expects ".dll.a" import libraries to be available. * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. CMake 3.17 Release Notes ************************ Changes made since CMake 3.16 include the following. New Features ============ Generators ---------- * "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar to the "Ninja" generator but can be used to build multiple configurations at once. * Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them. * Visual Studio Generators for VS 2010 and above now support specifying the "VCTargetsPath" value for project files in "CMAKE_GENERATOR_TOOLSET" setting. * Visual Studio Generators for VS 2010 and above learned to support .NET Standard and .NET Core. See the "DOTNET_TARGET_FRAMEWORK" target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK" variable. Languages --------- * The "Compile Features" functionality now offers meta-features for the CUDA language standard levels (e.g. "cuda_std_03", "cuda_std_14"). See "CMAKE_CUDA_KNOWN_FEATURES". Compilers --------- * The IBM XL Fortran compiler is now supported by the "Ninja" generator. Command-Line ------------ * "cmake(1)" gained a "--debug-find" command-line option to enable additional human-readable output on where find commands search. * "cmake(1)" gained a "--trace-format" command-line option that can be used to set the "--trace" output format. Currently, the old human readable and the new JSON format are supported. The new JSON format is easier to parse automatically, than the existing format. * "cmake(1)" gained a "-E rm" command-line tool that can be used to remove directories and files. This supersedes the existing "-E remove" and "-E remove_directory" tools and has better semantics. Commands -------- * The "add_custom_command()" command learned to interpret paths in "DEPENDS" arguments that are specified relative to the current binary directory. * The "foreach()" learned a new option "ZIP_LISTS" to iterate over multiple lists simultaneously. * The "load_cache(READ_WITH_PREFIX)" command mode is now allowed when using "cmake -P" to Run a Script. * The "message()" command learned to output context provided in the "CMAKE_MESSAGE_CONTEXT" variable for log levels "NOTICE" and below. Enable this output with the new "--log-context" command-line option or "CMAKE_MESSAGE_CONTEXT_SHOW" variable. * The "message()" command gained new keywords "CHECK_START", "CHECK_PASS" and "CHECK_FAIL". * "target_compile_options()" command now honors the "BEFORE" keyword more consistently. See policy "CMP0101". * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. Variables --------- * A "CMAKE_CTEST_ARGUMENTS" variable was added to specify a list of command-line arguments passed to CTest when running through the "test" (or "RUN_TESTS") target of the generated build system. * The following variables are now defined inside a "function()": * "CMAKE_CURRENT_FUNCTION" * "CMAKE_CURRENT_FUNCTION_LIST_DIR" * "CMAKE_CURRENT_FUNCTION_LIST_FILE" * "CMAKE_CURRENT_FUNCTION_LIST_LINE" * The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY" target property were introduced to select the CUDA runtime library used when linking targets that use CUDA. * The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. * The "CMAKE_EXPORT_COMPILE_COMMANDS" variable now takes its initial value from the "CMAKE_EXPORT_COMPILE_COMMANDS" environment variable if no explicit configuration is given. * The "CMAKE__COMPILER_LAUNCHER" variable, if not set explicitly, now takes its initial value from the "CMAKE__COMPILER_LAUNCHER" environment variable. * The "CMAKE_MESSAGE_LOG_LEVEL" variable can now be used to persist a log level between CMake runs, unlike the "--log-level" command line option which only applies to that particular run. * The "CMAKE_XCODE_SCHEME_ENVIRONMENT" variable and "XCODE_SCHEME_ENVIRONMENT" target property were added to tell the "Xcode" generator to set the value of the "Custom Working Directory" schema option. Properties ---------- * The "AIX_EXPORT_ALL_SYMBOLS" target property and associated "CMAKE_AIX_EXPORT_ALL_SYMBOLS" variable were created to optionally explicitly disbale automatic export of symbols from shared libraries on AIX. * The "DEPRECATION" target property was added to mark a target as deprecated. If a linked target is marked as deprecated, a warning with the deprecation message is issued at generate time. * The "INSTALL_NAME_DIR" target property now supports "generator expressions". In particular, the "$" generator expression can be used to set the directory relative to the install- time prefix. * Target properties "OSX_COMPATIBILITY_VERSION" and "OSX_CURRENT_VERSION" were added to set the "compatibility_version" and "curent_version" respectively on macOS. For backwards compatibility, if these properties are not set, "SOVERSION" and "VERSION" are used respectively as fallbacks. * The "VS_DOTNET_DOCUMENTATION_FILE" target property was added to tell Visual Studio Generators to generate a "DocumentationFile" reference in ".csproj" files. Modules ------- * The "ExternalProject" module "ExternalProject_Add()" command gained a "GIT_SUBMODULES_RECURSE" option to specify whether Git submodules should be updated recursively. The default is on to preserve existing behavior. * The "FindCUDAToolkit" module was added to find the CUDA Toolkit without enabling CUDA as a language. * The "FindCURL" module learned to find CURL using the "CURLConfig.cmake" package configuration file generated by CURL?s cmake buildsystem. It also gained a new "CURL_NO_CURL_CMAKE" option to disable this behavior. * The "FindFLEX" module?s "FLEX_TARGET" command now runs "flex" with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy "CMP0098". * The "FindLibArchive" module now provides an imported target for libarchive. * The "FindPython" module has learned to find Python components in active virtual environments managed by "conda". * The "FindPython3" and "FindPython" modules gained, respectively, variable "Python3_SOABI" and "Python_SOABI" giving the standard extension suffix for modules. * The "FindLibXml2" module now provides an imported target for the "xmllint" executable Autogen ------- * "AUTOMOC" and "AUTOUIC" learned to process headers with a ".hh" extension. See policy "CMP0100". CTest ----- * The "CTEST_CONFIGURATION_TYPE" variable is now set from the command line when "ctest(1)" is invoked with "-C ". * The "ctest(1)" gained support for Dr. Memory to run memcheck runs. * The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found. * The "ctest(1)" tool gained a "--repeat :" option to specify conditions in which to repeat tests. This generalizes the existing "--repeat-until-fail " option to add modes for "until-pass" and "after-timeout". * The "ctest_test()" command gained a "REPEAT :" option to specify conditions in which to repeat tests. CPack ----- * The "CPack DragNDrop Generator" learned to use the "CPACK_DMG__FILE_NAME" variable to set a custom filename when packaging components into their own DMGs. * The "CPack DragNDrop Generator" learned to handle RTF formatted license files. When "CPACK_DMG_SLA_DIR" variable is set, ".license.rtf" is considered, but only as a fallback when the plaintext (".txt") file is not found in order to maintain backwards compatibility. * The "CPack NSIS Generator" gained a new variable "CPACK_NSIS_MUI_HEADERIMAGE" to set the header image. To not break existing setups, it still defaults to "CPACK_PACKAGE_ICON" if the new variable is not set. * The "CPack NSIS Generator" now supports "CPACK_NSIS_UNINSTALL_NAME". This can be used to specify the name of the Uninstall program. * The "CPack NSIS Generator" now supports "CPACK_NSIS_WELCOME_TITLE" and "CPACK_NSIS_WELCOME_TITLE_3LINES". These can be used to specify the welcome page title and display it in 3 lines. * The "CPack NSIS Generator" now supports "CPACK_NSIS_FINISH_TITLE" and "CPACK_NSIS_FINISH_TITLE_3LINES". These can be used to specify the finish page title and display it in 3 lines. * The "CPack productbuild Generator" gained option "CPACK_PRODUCTBUILD_BACKGROUND" to specify a background image for the macOS installer. Other ----- * "ccmake(1)" now displays cache values using colors based on the entry type if the terminal supports color. * "ccmake(1)" now displays messages and a progress bar during configure and generate. It will keep the output displayed if any errors or warnings occurred. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policy "CMP0068" and policy "CMP0069" ("CMP0067" 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 "CPack PackageMaker Generator" generator has been deprecated because Xcode no longer distributes the PackageMaker tools. The undocumented "OSXX11" generator has also been deprecated. * The "cmake(1)" command-line "-E remove" and "-E remove_directory" tools are deprecated in favor of the new "-E rm" tool. The older tools always returned 0 if a named path did not exist even without the force option and cannot be fixed without breaking compatibility, and so have been superseded. Other Changes ============= * The "file API" index file now emits a "multiConfig" flag specifying whether or not the generator supports multiple output configurations. * Target link properties "INTERFACE_LINK_OPTIONS", "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now transitive over private dependencies on static libraries. See policy "CMP0099". * When using MinGW tools, the "find_library()" command no longer finds ".dll" files by default. Instead it expects ".dll.a" import libraries to be available. * The "MinGW Makefiles" generator no longer issues an error if "sh.exe" is present in the environment?s "PATH". * The "Ninja" generator now prefers the first ninja build tool to appear in the "PATH" no matter whether it is called "ninja-build", "ninja", or "samu". Previously the first of those names to appear anywhere in the "PATH" would be preferred. * With SDCC the "sdar" tool is now preferred over "sdcclib" as librarian. The latter was deprecated by SDCC 3.2.0 and removed in SDCC 3.8.6. * With SDCC the default flags no longer include any target-specific flags. Previously the default flags were hard-coded for 8051. * The "CMAKE_VS_GLOBALS" variable value now applies during compiler identification and in targets created by the "add_custom_target()" command. * The "Xcode" generator no longer hard-codes "-Wmost", "-Wno-four- char-constants", and "-Wno-unknown-pragmas" warning flags. From st_trzaska at poczta.fm Thu Feb 13 17:48:25 2020 From: st_trzaska at poczta.fm (St.Trzaska) Date: Thu, 13 Feb 2020 23:48:25 +0100 Subject: [CMake] cmake config. error Message-ID: Hello, please help. I have problem with installing gtest/gmock on MINGW64. Attachyed are Terminal output and CmakeOutput.log best regards St.Trzasak -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeOutput.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Terminal_output.txt URL: From sancelot at numalliance.com Fri Feb 14 04:49:22 2020 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Fri, 14 Feb 2020 10:49:22 +0100 Subject: [CMake] exporting and using an exported package in the same project Message-ID: Hi, I am trying to use a third party library (https://github.com/zaphoyd/websocketpp) It exports a Config.cmake file when building , but I want to use it from my workspace in which I cloned it . I tried using find_package(websocketpp CONFIG), but cmake replies websocketpp_DIR not found. The question is: can I use an exported package from the workspace exporting it ? Regards, S.Ancelot -------------- next part -------------- An HTML attachment was scrubbed... URL: From infikamal5 at gmail.com Wed Feb 19 05:35:42 2020 From: infikamal5 at gmail.com (Kamal Selvam) Date: Wed, 19 Feb 2020 11:35:42 +0100 Subject: [CMake] Building Opencv and linking its library as external project Message-ID: Hello, I started learning CMAKE recently. I am encountering the philosophy of targets and properties since version 3.0. I have a project where I should build OpenCV residing in my project folder as /myproject/third-party/opencv and then link it's library to my own target. After searching a lot on stack overflow and internet, I always find CMake scripts of version < 2.8. Every single answer is unique. I could not find any proper example of building a third-party libraries the right way, exporting them and linking them with my own targets. Could some guide me or post a example of best way to build a external project like opencv residing inside the project folder and linking it's library to my own targets. Thank you, Best regards, Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen.dettmer at gmail.com Wed Feb 26 13:07:01 2020 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Wed, 26 Feb 2020 19:07:01 +0100 Subject: [CMake] cmake, ccache, CCACHE_BASEDIR: wrong paths in compiler error messages Message-ID: Hi, I hope I can still post here? I don't have a "discourse" account. Let me summarize what we have here. We have projects with some hunderds CMakeLists.txt. The "main" typically use several add_subdirectory directives for the use libraries in form of: add_subdirectory(${path_lib_a} liba) For each, cmake creates a subdirectory (such as here "liba") in the build directory. Normally cmake uses absolute paths, so compiler error messages contain absolute paths as well. Now we are also using ccache. Since we use the same libs in many places, of course we want to share the ccache results. For multiple builddirs I was not able to get it working, but at least for the case of multiple sourcedirs that have there builddirs below. This is useful if several people work on same code (shared ccache) or if you have several checkouts, for example for similar variants or source code branches. In most of these cases, many libraries are the same, so caching in theory should be very effective. Since ccache also compares compiler arguments of course and it's include arguments include absolute paths, ccaching across src trees does not work, so we have to set CCACHE_BASEDIR. Technically cmake creates a wrapper file used as CMAKE_CXX_COMPILER_LAUNCHER in BUILDDIR with "export CCACHE_BASEDIR=$TOPSRCDIR" and then calling essentially "ccache $CXX "$@"". Now ccache works fine across source trees. At the end of the mail some cmake excerpt in case it is useful. But unfortunately now IDEs (like Vim, QTCreator...) are unable to jump to compiler errors, because now the paths are relative to the directory where the compiler (wrapper) is called. Normally the IDEs know this from make output: make[2]: Entering directory '/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810' but unfortunately for "add_subdirectory", cmake uses some own logic visible only when running make VERBOSE=1, which looks like: make[2]: Entering directory '/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810' [ 14%] Building CXX object.... cd /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/libA && /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/ccache-CXX /opt/bt/cross/i586-pc-linux-gnu/gcc-4.4.3/usr/bin/i586-pc-linux-gnu-g++ ... -o CMakeFiles/libA.dir/home/sdettmer/work/tisc-src/.../libA/src/File1.cpp.o -c /home/sdettmer/work/tisc-src/.../libA /src/File1.cpp Compiler errrors now are not relative to the path told by make (here cmake-build-debug-1810), but relative to the "cd .../libA", which is normally not even visible: In file included from ../../...../libA/File1.cpp:10: .... Now the IDE looks for path relative to cmake-build-debug-1810, because it does not know about the "cd ...cmake-build-debug-1810/libA" and does not find the file. We discussed this in the team, I searched the web for several hours now, but I don't find any solution. Due to the absolute paths requirement of cmake I think I must use CCACHE_BASEDIR, but when I do, IDEs don't find the files. I didn't find a way to make cmake output "Entering directory" lines. Since we are probably not the only ones who use cmake and ccache, we probably doing it wrong and miss an important point. How is ccache supposed to be used correctly? I saw many examples in the internet, but none seem to correctly work with CCACHE_BASEDIR, and without CCACHE_BASEDIR cache is not efficient and almost useless and shared cache even completely useless (never hits). Any help appreciated! As only workaround we could find, I now manually add: echo "make[77]: Entering directory '$(pwd)'" in the ccache-wrapper. This helps a bit, but generates heaps of output (entering line for each single file) and I think it breaks when using "make -j". Steffen CMakeLists.txt excerpt: foreach(_BT_LANG "C" "CXX") file(WRITE "${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}" "" "#!/bin/sh\n" "# Xcode generator doesn't include the compiler as the first arg:\n" "[ \"$1\" = \"${CMAKE_${_BT_LANG}_COMPILER}\" ] && shift\n" "\n" "# \"Convert\" cmake variable to an env to allow shared caches\n" "export CCACHE_BASEDIR=${_BT_CCACHE_BASEDIR}\n" "export CCACHE_SLOPPINESS=file_macro,time_macros\n" "# export CCACHE_NODIRECT=set\n" "export CCACHE_CPP2=set\n" "[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]: Entering directory '$(pwd)'\"\n" "\"${_BT_${_BT_LANG}_LAUNCHER}\" \"${CMAKE_${_BT_LANG}_COMPILER}\" \"$@\"\n" "[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]: Leaving directory '$(pwd)'\"\n" ) execute_process(COMMAND chmod a+rx "${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}") endforeach() ... CHECK_CXX_COMPILER_FLAG(-fdiagnostics-color=auto CXX_FLAG_DIAGNOSTIC_COLOR_AUTO) if (${CXX_FLAG_DIAGNOSTIC_COLOR_AUTO}) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fdiagnostics-color=auto") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fdiagnostics-color=auto") endif() endif() set(CMAKE_C_COMPILER_LAUNCHER "${CMAKE_BINARY_DIR}/ccache-C") set(CMAKE_CXX_COMPILER_LAUNCHER "${CMAKE_BINARY_DIR}/ccache-CXX") From robert.maynard at kitware.com Thu Feb 27 13:22:03 2020 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 27 Feb 2020 13:22:03 -0500 Subject: [CMake] [REMINDER] CMake transition to discourse Message-ID: Reminder the CMake Discourse forum ( https://discourse.cmake.org ) is the preferred location for CMake questions and discussions. The current mailman-based mailing lists will be disabled in April 2020, and their archives will remain available after that. Reminder for those who prefer email over web forums, the Forum Help page includes instructions to participate in the forum purely via email. Creating topics in the forum via email (and receiving replies) is supported *with or without* registering a user account. From pietro.paolini at cognitivecredit.com Fri Feb 28 04:18:48 2020 From: pietro.paolini at cognitivecredit.com (Pietro Paolini) Date: Fri, 28 Feb 2020 09:18:48 +0000 Subject: [CMake] Build cmake dependency Message-ID: <1582881528.2683.0@cognitivecredit.com> Hi all, I really cannot say I am an expert with CMake however I have been using it for a while now, even though mainly by copying and pasting snippet of code from the web therefore not understanding things properly. I am working on a project which depends on a libary which is itself built using CMake, I'd like my project to build the library itself during its own build and I can successfully do that by adding the folder to the root CMakeLists.txt of my current prject, however I couldn't find a way to include its headers and link the shared object. I had to resort to a bash script which compiles and installs the dependency in a pre-defined location and add such location to my project's CMake's setting file through the use of include_directories()/link_directories(). It works but I'd like to get CMake to do what I want and not having to find workaroun, I am pretty confident I am missing something here, is there a better way to do that ? Thanks, Pietro From scott at towel42.com Fri Feb 28 12:42:01 2020 From: scott at towel42.com (Scott Bloom) Date: Fri, 28 Feb 2020 17:42:01 +0000 Subject: [CMake] Build cmake dependency In-Reply-To: <1582881528.2683.0@cognitivecredit.com> References: <1582881528.2683.0@cognitivecredit.com> Message-ID: You may want to move this to https://discourse.cmake.org/, as this mailing list is going away (note, Im not with the cmake org at all.. just a user..) That said,typically, when a CMake based library is included into a larger cmake project, it will set some variables. SUBLIB_DIR for instance.. so you would then, in the top project do something like include_directories( ${SUBLIB_DIR }/include ) If it doesn't create the directory, I would do the following set( SUBLIB_DIR ${CMAKE_SOURCE_DIR}/SubLibName ) add_subdirectory( ${SUBLIB_DIR} ) for the output of the library, you can in your executable target_link_libraries directly list the target project name target_link_libraries( MyExe SubLib ) Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Pietro Paolini Sent: Friday, February 28, 2020 1:19 AM To: cmake at cmake.org Subject: [CMake] Build cmake dependency Hi all, I really cannot say I am an expert with CMake however I have been using it for a while now, even though mainly by copying and pasting snippet of code from the web therefore not understanding things properly. I am working on a project which depends on a libary which is itself built using CMake, I'd like my project to build the library itself during its own build and I can successfully do that by adding the folder to the root CMakeLists.txt of my current prject, however I couldn't find a way to include its headers and link the shared object. I had to resort to a bash script which compiles and installs the dependency in a pre-defined location and add such location to my project's CMake's setting file through the use of include_directories()/link_directories(). It works but I'd like to get CMake to do what I want and not having to find workaroun, I am pretty confident I am missing something here, is there a better way to do that ? Thanks, Pietro -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org