From Caleb.Pentecost at cognex.com Thu Mar 1 17:13:41 2018 From: Caleb.Pentecost at cognex.com (Pentecost, Caleb) Date: Thu, 1 Mar 2018 22:13:41 +0000 Subject: [CMake] set_source_files_properties and custom targets Message-ID: Howdy, I'm running into an issue with a custom target dependency that I want to assign to all source files. In this case, I have a helper library (lets call it utils) that builds a couple source files that each depend on an output file from a separate process. It would look something like this: System/libs/utils/CMakeLists.txt: # Show CMake how to build the file we need add_custom_command( OUTPUT out.txt DEPENDS C:/in.txt COMMAND ) # Create a target that requires the output file add_custom_target(customTarget DEPENDS out.txt # Create a list of source files set (SOURCE_FILES utils.cpp helpers.cpp ) # Make all source files depend on the new target set_source_files_properties( ${SOURCE_FILES} OBJECT_DEPENDS customTarget ) # Assign source files to utils library, etc. <...> When CMake runs, two folders are created (in the folder bin/obj/system/libs/utils/CMakeFiles). They are called utils.dir and customTarget.dir. In utils.dir, we find our build.make file and see the rules to produce the compiled object as well as the custom target: bin/obj/system/libs/utils/CMakeFiles/build.make: # Miscellaneous assignments at the top <...> # Rule to make custom target system/libs/utils/CMakeFiles/customTarget: out.txt out.txt: C:/in.txt # Rules to make the files system/libs/utils/CMakeFiles/utils.dir/utils.o: customTarget system/libs/utils/CMakeFiles/utils.dir/helpers.o: customTarget # Other rules, assignments, etc. <...> The problem seems to be how the custom target is defined. For the object files, its simply the target name. The target itself appears to have a fully qualified path. This is giving me the following error: gmake[2]: *** No rule to make target `customTarget, needed by ` system/libs/utils/CMakeFiles/utils.dir/helpers.o'. Stop. If I manually edit the make file and change the target to the fully qualified name (and manually execute make) then the compilation succeeds. Is there something that I am doing wrong that is incorrectly assigning the target name? Is there an alternative to the "set_source_files_properties" command that would behave better? Thank you in advance for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From cameron at promon.no Fri Mar 2 06:22:14 2018 From: cameron at promon.no (Cameron Palmer) Date: Fri, 2 Mar 2018 11:22:14 +0000 Subject: [CMake] add_custom_target Message-ID: I?m using ExternalProject_Add to download a Git project that is a pre-requisite of my project. For the sake of the discussion I?ve wrapped OpenSSL and Boost in this manner placing tagged version of the source in my repo. Building them isn?t really a problem, they run, take a long time compiling. The thing is, they should only compile once unless the tag changes. From the source it seems once you?ve used git you?ll always trigger the whole External Build sequence which is a pain since it is slow. So? I?ve been trying to create an external build just for the Git checkout and a second for the compilation. Which goes well enough, but I still need the glue to signal that he source is ?dirty? and it should recompile the project. The glue I?m trying to use is add_custom_command and add_custom_target, but add_custom_target seems? broken if only in concept. I?ve been trying to write a file to the system with the SHA tag and only touch it when it changes, but I cannot convince the ExternalProject that builds the library to not run. Any tips that might make this work? From mark.dewit at iesve.com Fri Mar 2 07:02:47 2018 From: mark.dewit at iesve.com (Mark De Wit) Date: Fri, 2 Mar 2018 12:02:47 +0000 Subject: [CMake] add_custom_target In-Reply-To: References: Message-ID: <3f5ad05edf8c4d528120f505d39318d7@iesve.com> Hi Cameron, For boost integration into our cmake project, we're using this (slightly customised for our use): https://github.com/Orphis/boost-cmake It unzips boost into your build folder, and builds the required packages on demand (not all of boost, just the boost modules you use). It works well for incremental builds (doesn't rebuild unless you clear your build folder), and for clean builds the individual boost modules build fast enough to be insignificant. I'd also point out that the build time increase is somewhat balanced out by not fetching tens of thousands files from source control... This may help shape your thinking? Mark -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Cameron Palmer Sent: 02 March 2018 11:22 To: cmake at cmake.org Subject: [CMake] add_custom_target I?m using ExternalProject_Add to download a Git project that is a pre-requisite of my project. For the sake of the discussion I?ve wrapped OpenSSL and Boost in this manner placing tagged version of the source in my repo. Building them isn?t really a problem, they run, take a long time compiling. The thing is, they should only compile once unless the tag changes. From the source it seems once you?ve used git you?ll always trigger the whole External Build sequence which is a pain since it is slow. So? I?ve been trying to create an external build just for the Git checkout and a second for the compilation. Which goes well enough, but I still need the glue to signal that he source is ?dirty? and it should recompile the project. The glue I?m trying to use is add_custom_command and add_custom_target, but add_custom_target seems? broken if only in concept. I?ve been trying to write a file to the system with the SHA tag and only touch it when it changes, but I cannot convince the ExternalProject that builds the library to not run. Any tips that might make this work? -- 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 From cameron at promon.no Fri Mar 2 08:21:08 2018 From: cameron at promon.no (Cameron Palmer) Date: Fri, 2 Mar 2018 13:21:08 +0000 Subject: [CMake] add_custom_target In-Reply-To: <3f5ad05edf8c4d528120f505d39318d7@iesve.com> References: <3f5ad05edf8c4d528120f505d39318d7@iesve.com> Message-ID: Interesting project, so thanks for the link! The problem we have is that changing the build system for external projects isn?t really acceptable. In this boost-cmake build they ripped out jam and replaced it with cmake, which is kind of cool, but such action is not a good plan for OpenSSL. If I recall they state (somewhere) in the documentation, don?t do this and even if it did work, I wouldn?t want to support it. Furthermore, it looks like you?d also be stuck using 1.63.0 of Boost. In summary, there is a lot of compromise involved in trying to replace a build-system, better to wrap it. Cameron. > On 2 Mar 2018, at 13:02, Mark De Wit wrote: > > Hi Cameron, > > For boost integration into our cmake project, we're using this (slightly customised for our use): > https://github.com/Orphis/boost-cmake > > It unzips boost into your build folder, and builds the required packages on demand (not all of boost, just the boost modules you use). > > It works well for incremental builds (doesn't rebuild unless you clear your build folder), and for clean builds the individual boost modules build fast enough to be insignificant. I'd also point out that the build time increase is somewhat balanced out by not fetching tens of thousands files from source control... > > This may help shape your thinking? > > Mark > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Cameron Palmer > Sent: 02 March 2018 11:22 > To: cmake at cmake.org > Subject: [CMake] add_custom_target > > I?m using ExternalProject_Add to download a Git project that is a pre-requisite of my project. For the sake of the discussion I?ve wrapped OpenSSL and Boost in this manner placing tagged version of the source in my repo. > > Building them isn?t really a problem, they run, take a long time compiling. The thing is, they should only compile once unless the tag changes. From the source it seems once you?ve used git you?ll always trigger the whole External Build sequence which is a pain since it is slow. So? I?ve been trying to create an external build just for the Git checkout and a second for the compilation. Which goes well enough, but I still need the glue to signal that he source is ?dirty? and it should recompile the project. > > The glue I?m trying to use is add_custom_command and add_custom_target, but add_custom_target seems? broken if only in concept. I?ve been trying to write a file to the system with the SHA tag and only touch it when it changes, but I cannot convince the ExternalProject that builds the library to not run. > > Any tips that might make this work? > -- > > 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 From mark.dewit at iesve.com Fri Mar 2 11:28:17 2018 From: mark.dewit at iesve.com (Mark De Wit) Date: Fri, 2 Mar 2018 16:28:17 +0000 Subject: [CMake] add_custom_target In-Reply-To: References: <3f5ad05edf8c4d528120f505d39318d7@iesve.com> Message-ID: <2ee8e37df8424fed8a704d97a27b05e1@iesve.com> Oh good point on OpenSSL, their official build steps are awkard enough, let alone trying to emulate them in CMake! For what it's worth, we've upgraded boost-cmake to Boost 1.65 so far with no changes required to any of the modules we use. The other 3rd party module manager we're looking into is Conan (conan.io), which can create CMake import libraries / targets. It's a complex tool to understand, though. I see in your mail that you're using a file to write SHA tags of your current 3rd party modules. Boost-cmake does a similar thing, but it stores it in the cmake cache, perhaps slightly easier to work with? Do I understand correctly that you're using this external file as a dependency from which to trigger a 3rd party module build? But cmake isn't detecting changes / running the custom commands that are dependent on that file? Might it help to add the file to one of your own projects, eg one of the projects that depends on boost / openssl? From memory, I believe cmake only cares about files if they're actually part of a target (unsure if custom targets count)? Mark -----Original Message----- From: Cameron Palmer [mailto:cameron at promon.no] Sent: 02 March 2018 13:21 To: Mark De Wit Cc: cmake at cmake.org Subject: Re: add_custom_target Interesting project, so thanks for the link! The problem we have is that changing the build system for external projects isn?t really acceptable. In this boost-cmake build they ripped out jam and replaced it with cmake, which is kind of cool, but such action is not a good plan for OpenSSL. If I recall they state (somewhere) in the documentation, don?t do this and even if it did work, I wouldn?t want to support it. Furthermore, it looks like you?d also be stuck using 1.63.0 of Boost. In summary, there is a lot of compromise involved in trying to replace a build-system, better to wrap it. Cameron. > On 2 Mar 2018, at 13:02, Mark De Wit wrote: > > Hi Cameron, > > For boost integration into our cmake project, we're using this (slightly customised for our use): > https://github.com/Orphis/boost-cmake > > It unzips boost into your build folder, and builds the required packages on demand (not all of boost, just the boost modules you use). > > It works well for incremental builds (doesn't rebuild unless you clear your build folder), and for clean builds the individual boost modules build fast enough to be insignificant. I'd also point out that the build time increase is somewhat balanced out by not fetching tens of thousands files from source control... > > This may help shape your thinking? > > Mark > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Cameron Palmer > Sent: 02 March 2018 11:22 > To: cmake at cmake.org > Subject: [CMake] add_custom_target > > I?m using ExternalProject_Add to download a Git project that is a pre-requisite of my project. For the sake of the discussion I?ve wrapped OpenSSL and Boost in this manner placing tagged version of the source in my repo. > > Building them isn?t really a problem, they run, take a long time compiling. The thing is, they should only compile once unless the tag changes. From the source it seems once you?ve used git you?ll always trigger the whole External Build sequence which is a pain since it is slow. So? I?ve been trying to create an external build just for the Git checkout and a second for the compilation. Which goes well enough, but I still need the glue to signal that he source is ?dirty? and it should recompile the project. > > The glue I?m trying to use is add_custom_command and add_custom_target, but add_custom_target seems? broken if only in concept. I?ve been trying to write a file to the system with the SHA tag and only touch it when it changes, but I cannot convince the ExternalProject that builds the library to not run. > > Any tips that might make this work? > -- > > 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 From bsferrazza at avnera.com Fri Mar 2 13:04:00 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Fri, 2 Mar 2018 10:04:00 -0800 Subject: [CMake] failure to build Cmake to / against non-standard directory under Linux Message-ID: I have a completely insulated boostrapped toolchain+binaries setup (located under /home/tools), following much of the Linux From Scratch book, that has been able to build everything that I throw at it. Most things just work with a simple --prefix option, as I have also edited the GCC specs file to include my /home/tools/include directory (using -isystem) and link against my /home/tools/lib directory (also with an rpath set, so that all binaries I build are complete insulated from the host libraries). The lone exception to this is Cmake. It appears to have a lot of hardcoded paths in its build environment to standard /usr/* directories. I first got wind that something was awry when Cmake 3.10.2 claimed my compiler, GCC 7.3.0, isn't C++11 compliant. Clearly this isn't the case, given that it's the latest release. So I then tried building Cmake 3.9.6, which doesn't require C++11, and it was finding zlib and other libraries under /usr/lib as opposed to my /home/tools/lib. I don't even have LD_LIBRARY_PATH set, as I use rpath in the specs file like I mentioned. Can anyone provide any help into how I can get Cmake to build against non-standard include and library locations? Thank you, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry.Mallon at codex.online Fri Mar 2 14:12:42 2018 From: Harry.Mallon at codex.online (Harry Mallon) Date: Fri, 2 Mar 2018 19:12:42 +0000 Subject: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib Message-ID: <01010161e821754d-16a08f67-c285-438c-b3e2-d41f21884743-000000@us-west-2.amazonses.com> Hello all, When making a pure Swift bundle Xcode automatically copies `libswiftCore.dylib` as follows. ``` ./Tests/SwiftOnly/Debug/SwiftOnly.app ??? Contents ??? Frameworks ? ??? libswiftCore.dylib ??? Info.plist ??? MacOS ? ??? SwiftOnly ??? PkgInfo ??? Resources ??? libswiftRemoteMirror.dylib ``` When I try to run the output I get a dynamic linking error. I can reproduce this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the CMake source tree) in `add_executable` and trying to run the result. ``` % ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly dyld: Library not loaded: @rpath/libswiftCore.dylib Referenced from: .../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly Reason: image not found zsh: abort ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly ``` It seems that the rpath should be set to `@loader_path/../Frameworks`. I am not a Swift maestro so not exactly sure on the details of how this works. After running `install_name_tool -add_rpath "@loader_path/../Frameworks" ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine. Does anyone have any idea what to do? Is it a missing CMake Swift feature? We are currently working around it by manually adding the rpath with a cmake step. Harry Harry Mallon Senior Software Engineer [http://codex.online/?action=asset&id=E3D62C3D-A12C-447D-87A5-F36E7C2AA9A4] T +44 203 7000 989 60 Poland Street | London | England | W1F 7NT [http://codex.online/?action=asset&id=6F42BDF2-3C6D-4054-A5D2-277E0E535942] Three Billboards Blade Runner 2049 I, Tonya -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsferrazza at avnera.com Fri Mar 2 17:43:13 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Fri, 2 Mar 2018 14:43:13 -0800 Subject: [CMake] failure to build Cmake to / against non-standard directory under Linux In-Reply-To: References: Message-ID: I was able to get 3.9.6 to compile setting CMAKE_PREFIX_PATH to the same path that I pass .bootstrap with --prefix. I also had to patch the Modules/Compiler/GNU.cmake file to use -idirafter rather than -isystem as the latter leads to issues with #include_next. I'm still perplexed why 3.10.2 thinks doesn't think my compiler, GCC 7.3.0, is C++11 compliant. The only thing I can think of is that I am using a somewhat older version of Glibc, 2.19, as that is the newest version compatible with the host's kernel of 2.6.18. However, that glibc was released in 2014, so I would think that wouldn't be the case. On Fri, Mar 2, 2018 at 10:04 AM, Ben Sferrazza wrote: > I have a completely insulated boostrapped toolchain+binaries setup > (located under /home/tools), following much of the Linux From Scratch book, > that has been able to build everything that I throw at it. Most things > just work with a simple --prefix option, as I have also edited the GCC > specs file to include my /home/tools/include directory (using -isystem) and > link against my /home/tools/lib directory (also with an rpath set, so that > all binaries I build are complete insulated from the host libraries). The > lone exception to this is Cmake. It appears to have a lot of hardcoded > paths in its build environment to standard /usr/* directories. > > I first got wind that something was awry when Cmake 3.10.2 claimed my > compiler, GCC 7.3.0, isn't C++11 compliant. Clearly this isn't the case, > given that it's the latest release. So I then tried building Cmake 3.9.6, > which doesn't require C++11, and it was finding zlib and other libraries > under /usr/lib as opposed to my /home/tools/lib. I don't even have > LD_LIBRARY_PATH set, as I use rpath in the specs file like I mentioned. Can > anyone provide any help into how I can get Cmake to build against > non-standard include and library locations? > > Thank you, > Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas.soltic at orange.fr Fri Mar 2 18:20:39 2018 From: lucas.soltic at orange.fr (=?utf-8?Q?Lucas_=C5=A0olti=C4=87?=) Date: Sat, 3 Mar 2018 00:20:39 +0100 Subject: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib In-Reply-To: <01010161e821754d-16a08f67-c285-438c-b3e2-d41f21884743-000000@us-west-2.amazonses.com> References: <01010161e821754d-16a08f67-c285-438c-b3e2-d41f21884743-000000@us-west-2.amazonses.com> Message-ID: <6A9C5A7B-29D7-42EE-AC9E-4E724C28D153@orange.fr> You miss a runtime search path when linking your executable. And this is what you achieved with install_name_tool with an additional step. To avoid this additional step, see https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html or https://stackoverflow.com/questions/42613881/adding-run-time-shared-library-search-path-to-executable-at-compile-time-clang By the way this is not related to Swift at all. Lucas > Le 2 mars 2018 ? 20:12, Harry Mallon a ?crit : > > Hello all, > > When making a pure Swift bundle Xcode automatically copies `libswiftCore.dylib` as follows. > > ``` > ./Tests/SwiftOnly/Debug/SwiftOnly.app > ??? Contents > ??? Frameworks > ? ??? libswiftCore.dylib > ??? Info.plist > ??? MacOS > ? ??? SwiftOnly > ??? PkgInfo > ??? Resources > ??? libswiftRemoteMirror.dylib > ``` > When I try to run the output I get a dynamic linking error. I can reproduce this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the CMake source tree) in `add_executable` and trying to run the result. > > ``` > % ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > dyld: Library not loaded: @rpath/libswiftCore.dylib > Referenced from: .../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > Reason: image not found > zsh: abort ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > ``` > > It seems that the rpath should be set to `@loader_path/../Frameworks`. I am not a Swift maestro so not exactly sure on the details of how this works. After running `install_name_tool -add_rpath "@loader_path/../Frameworks" ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine. > > Does anyone have any idea what to do? Is it a missing CMake Swift feature? We are currently working around it by manually adding the rpath with a cmake step. > > Harry > Harry Mallon > Senior Software Engineer > > > > T +44 203 7000 989 > 60 Poland Street | London | England | W1F 7NT > > Three Billboards Blade Runner 2049 I, Tonya > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Mon Mar 5 05:59:01 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Mon, 5 Mar 2018 11:59:01 +0100 Subject: [CMake] using external library Message-ID: <119e5c58-b641-a1ee-a9b6-59180b23accf@numalliance.com> Hi, I need some external libraries in my project (eg a particular version of qt..) These external projects have been cloned locally , I could use ExternalProject_Add to clone it in my project. My major problem is that I will compile it each time and this is time and disk usage? consuming, for each users . I sounds to me better to have the compiled version available in my development system and use only header+binaries of this particular release. So, the scenario I would like to obtain : check if My Qt5 binaries are setted up in my system in a predefined directory (to not overlap with possible system one), if not setted up, then clone qt needed release and install it in my predefined system directory once (like /usr/local or a directory shared between users) . I hope you understood and it is enough clear .... Thanks Steph From kai.wolf at gmail.com Mon Mar 5 06:26:16 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Mon, 5 Mar 2018 12:26:16 +0100 Subject: [CMake] using external library In-Reply-To: <119e5c58-b641-a1ee-a9b6-59180b23accf@numalliance.com> References: <119e5c58-b641-a1ee-a9b6-59180b23accf@numalliance.com> Message-ID: Steph, what you want to achieve is better known as a *Superbuild* in the CMake world. You have several options here, but the most basic one is probably the following: You setup another repository which only builds all the external dependencies (such as Qt) and put them in a predefined place. In your actual project you could refer to those prebuilt libraries using the CMAKE_PREFIX_PATH variable, which should point to the install directory from your external build. This way all the external stuff will only be build once (probably via CI) and all your developers don't need to build all the dependencies themselves. Regarding the external package introspection. You could use find_package() to check, if the correct version of your external library has been found on the system and just use it. In any other case you check for the _NOTFOUND variable and set it up locally, with the installation target pointing to the CMAKE_PREFIX_PATH as mentioned above. On a personal note, I would not use such a build system layout myself, as it quickly becomes unclear from where a dependency is coming from and if the dependency has all the required flags and settings as needed for the software project. So you might want to reconsider a more cleaner layout. For inspiration you may have a look at the CMake configuration of the OpenChemistry project [1]. Greetings [1] https://github.com/OpenChemistry/openchemistry Kai Wolf http://kai-wolf.me/ kai.wolf at gmail.com 2018-03-05 11:59 GMT+01:00 St?phane Ancelot : > Hi, > > I need some external libraries in my project (eg a particular version of > qt..) > > These external projects have been cloned locally , I could use > ExternalProject_Add to clone it in my project. > > My major problem is that I will compile it each time and this is time and > disk usage consuming, for each users . > > I sounds to me better to have the compiled version available in my > development system and use only header+binaries of this particular release. > > So, the scenario I would like to obtain : > > check if My Qt5 binaries are setted up in my system in a predefined > directory (to not overlap with possible system one), if not setted up, then > > clone qt needed release and install it in my predefined system directory > once (like /usr/local or a directory shared between users) . > > I hope you understood and it is enough clear .... > > Thanks > > Steph > > > > > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.frankish at outlook.com Mon Mar 5 06:45:00 2018 From: john.frankish at outlook.com (John Frankish) Date: Mon, 5 Mar 2018 11:45:00 +0000 Subject: [CMake] Compiling cmake-3.10.2 against ncursesw Message-ID: Hi, I've been trying to compile cmake-3.10.2 on a system that has only ncursesw using the ./bootstrap script. I could not find a way to tell ./bootstrap to use ncursesw, so I added the following to Modules/FindCurses.cmake set(CURSES_NEED_WIDE TRUE) ..this enables ./bootstrap to find libncursesw, but not libformw, so I also added: set(CURSES_FORM_LIBRARY "/usr/local/lib/libformw.so") ..and ./bootstrap completes successfully. However "make" fails when it cannot find form.h (even though it found /usr/local/include/ncursesw/ncurses.h). After symlinking /usr/local/include/ncursesw/form.h -> ../form.h, "make" completes successfully. Is there any easy way to use ./bootstrap on an ncursesw system? If Modules/FindCurses.cmake has the problems above when compiling cmake itself, won't it also have problems when compiling other stuff against ncursesw? Regards John From Harry.Mallon at codex.online Tue Mar 6 05:02:37 2018 From: Harry.Mallon at codex.online (Harry Mallon) Date: Tue, 6 Mar 2018 10:02:37 +0000 Subject: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib In-Reply-To: <6A9C5A7B-29D7-42EE-AC9E-4E724C28D153@orange.fr> References: <01010161e821754d-16a08f67-c285-438c-b3e2-d41f21884743-000000@us-west-2.amazonses.com> <6A9C5A7B-29D7-42EE-AC9E-4E724C28D153@orange.fr> Message-ID: Hi Lucas, With Swift there is a required standard dylib that must be included (and Xcode copies by default). So perhaps CMake should automatically add the rpath option to the Xcode command line? Harry From: Lucas ?olti? Date: Friday, 2 March 2018 at 23:20 To: Harry Mallon Cc: "cmake at cmake.org" Subject: Re: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib You miss a runtime search path when linking your executable. And this is what you achieved with install_name_tool with an additional step. To avoid this additional step, see https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html or https://stackoverflow.com/questions/42613881/adding-run-time-shared-library-search-path-to-executable-at-compile-time-clang By the way this is not related to Swift at all. Lucas Le 2 mars 2018 ? 20:12, Harry Mallon > a ?crit : Hello all, When making a pure Swift bundle Xcode automatically copies `libswiftCore.dylib` as follows. ``` ./Tests/SwiftOnly/Debug/SwiftOnly.app ??? Contents ??? Frameworks ? ??? libswiftCore.dylib ??? Info.plist ??? MacOS ? ??? SwiftOnly ??? PkgInfo ??? Resources ??? libswiftRemoteMirror.dylib ``` When I try to run the output I get a dynamic linking error. I can reproduce this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the CMake source tree) in `add_executable` and trying to run the result. ``` % ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly dyld: Library not loaded: @rpath/libswiftCore.dylib Referenced from: .../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly Reason: image not found zsh: abort ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly ``` It seems that the rpath should be set to `@loader_path/../Frameworks`. I am not a Swift maestro so not exactly sure on the details of how this works. After running `install_name_tool -add_rpath "@loader_path/../Frameworks" ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine. Does anyone have any idea what to do? Is it a missing CMake Swift feature? We are currently working around it by manually adding the rpath with a cmake step. Harry Harry Mallon Senior Software Engineer [Image removed by sender.] T +44 203 7000 989 60 Poland Street | London | England | W1F 7NT [Image removed by sender.] Three Billboards Blade Runner 2049 I, Tonya -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Tue Mar 6 05:49:13 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Tue, 6 Mar 2018 11:49:13 +0100 Subject: [CMake] toolchain Message-ID: Hi, My project needs being compiled for different targets : win32 (linux mingw32) / linux64 (Opensuse 13.2) / linux32 (Ubuntu 10.04) using toolchain is the right option isn't it ??? some people told me it was deprecated ? Regards, S.Ancelot From lucas.soltic at orange.fr Tue Mar 6 12:18:23 2018 From: lucas.soltic at orange.fr (Lucas Soltic) Date: Tue, 6 Mar 2018 18:18:23 +0100 Subject: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib In-Reply-To: References: <01010161e821754d-16a08f67-c285-438c-b3e2-d41f21884743-000000@us-west-2.amazonses.com> <6A9C5A7B-29D7-42EE-AC9E-4E724C28D153@orange.fr> Message-ID: <060AA7F1-A89E-416D-BC37-CC925509DACE@orange.fr> If full support for Swift was added to CMake yes why not. But I?m not a CMake developer and considering current Swift support it?s a bit early I think. I mean Swift support should come as a global feature, not just this specific point. > Le 6 mars 2018 ? 11:02, Harry Mallon a ?crit : > > Hi Lucas, > > With Swift there is a required standard dylib that must be included (and Xcode copies by default). So perhaps CMake should automatically add the rpath option to the Xcode command line? > > Harry > > From: Lucas ?olti? > Date: Friday, 2 March 2018 at 23:20 > To: Harry Mallon > Cc: "cmake at cmake.org" > Subject: Re: [CMake] Swift executables with MACOSX_BUNDLE fail to find libswiftCore.dylib > > You miss a runtime search path when linking your executable. And this is what you achieved with install_name_tool with an additional step. > > To avoid this additional step, see https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html > or > https://stackoverflow.com/questions/42613881/adding-run-time-shared-library-search-path-to-executable-at-compile-time-clang > > By the way this is not related to Swift at all. > > Lucas > > Le 2 mars 2018 ? 20:12, Harry Mallon a ?crit : > > Hello all, > > When making a pure Swift bundle Xcode automatically copies `libswiftCore.dylib` as follows. > > ``` > ./Tests/SwiftOnly/Debug/SwiftOnly.app > ??? Contents > ??? Frameworks > ? ??? libswiftCore.dylib > ??? Info.plist > ??? MacOS > ? ??? SwiftOnly > ??? PkgInfo > ??? Resources > ??? libswiftRemoteMirror.dylib > ``` > When I try to run the output I get a dynamic linking error. I can reproduce this by adding MACOSX_BUNDLE to `./Tests/SwiftOnly/CMakeLists.txt` (in the CMake source tree) in `add_executable` and trying to run the result. > > ``` > % ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > dyld: Library not loaded: @rpath/libswiftCore.dylib > Referenced from: .../Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > Reason: image not found > zsh: abort ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly > ``` > > It seems that the rpath should be set to `@loader_path/../Frameworks`. I am not a Swift maestro so not exactly sure on the details of how this works. After running `install_name_tool -add_rpath "@loader_path/../Frameworks" ./Tests/SwiftOnly/Debug/SwiftOnly.app/Contents/MacOS/SwiftOnly` it runs fine. > > Does anyone have any idea what to do? Is it a missing CMake Swift feature? We are currently working around it by manually adding the rpath with a cmake step. > > Harry > Harry Mallon > Senior Software Engineer > > > > T +44 203 7000 989 > 60 Poland Street | London | England | W1F 7NT > > > Three Billboards > Blade Runner 2049 > I, Tonya > > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razze at kodi.tv Wed Mar 7 03:57:38 2018 From: razze at kodi.tv (Kolja Lampe) Date: Wed, 07 Mar 2018 08:57:38 +0000 Subject: [CMake] GSOC 2018 CMake Project for Kodi Message-ID: Hey everybody, the Kodi Team is also offering a CMake related Project. Please check it out: *Description:* Kodi has its own system for building the many libraries Kodi depends on that supports most platforms (Linux, Android, OS X, iOS) and cross-compiling called depends. At the moment, it is implemented with autotools and hand-crafted Makefiles. This has lead to a lot of code duplication, poor maintainability, and not being very user-friendly. Also, it does not currently work on Windows. This task would be about replacing the current system with a new implementation in CMake that has better maintainability. *Expected outcome:* A CMake-based dependency build system that offers roughly the same features as depends (i.e. all required libraries covered, diverse platform support, crosscompilation). If the solution can also be applied to Windows by e.g. adding minimal CMake files to replace some UNIX-only build systems, that would be a big plus, but it is not necessary. *Skills preferred:* CMake, shell scripting, general familiarity with UNIX/Linux *Possible mentors:* wsnipex *Difficulty:* Medium *Type:* Infrastructure/Automation https://kodi.wiki/view/Google_Summer_of_Code/2018#Replacing_depends_with_a_CMake-based_system Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Mar 7 06:52:02 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 7 Mar 2018 22:52:02 +1100 Subject: [CMake] GSOC 2018 CMake Project for Kodi In-Reply-To: References: Message-ID: You may want to have a look at the new FetchContent module added in the 3.11 release (currently in release candidate stage). It already brings a production-tested dependency downloading system, but still leaves how to build those dependencies up to the project. It may form a good basis for the GSoC work and I can probably answer questions related to that module if needed. Also consider other existing systems which may have already sufficiently solved this problem for you or at least be useful for showing how aspects of the work could be done. There are a number of popular systems worth checking out that are often mentioned on this list, including hunter, Spack, cget and others (I'll let the various stakeholders in the relevant projects chime in with their views rather than me potentially misrepresent some). On Wed, Mar 7, 2018 at 7:57 PM, Kolja Lampe wrote: > Hey everybody, > > the Kodi Team is also offering a CMake related Project. > Please check it out: > > *Description:* Kodi has its own system for building the many libraries > Kodi depends on that supports most platforms (Linux, Android, OS X, iOS) > and cross-compiling called depends. At the moment, it is implemented with > autotools and hand-crafted Makefiles. This has lead to a lot of code > duplication, poor maintainability, and not being very user-friendly. Also, > it does not currently work on Windows. This task would be about replacing > the current system with a new implementation in CMake that has better > maintainability. > > *Expected outcome:* A CMake-based dependency build system that offers > roughly the same features as depends (i.e. all required libraries covered, > diverse platform support, crosscompilation). If the solution can also be > applied to Windows by e.g. adding minimal CMake files to replace some > UNIX-only build systems, that would be a big plus, but it is not necessary. > > *Skills preferred:* CMake, shell scripting, general familiarity with > UNIX/Linux > > *Possible mentors:* wsnipex > > *Difficulty:* Medium > > *Type:* Infrastructure/Automation > > https://kodi.wiki/view/Google_Summer_of_Code/2018#Replacing_ > depends_with_a_CMake-based_system > > Thanks! > > -- > > 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 > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Wed Mar 7 16:22:38 2018 From: kgt at lanl.gov (Thompson, KT) Date: Wed, 7 Mar 2018 21:22:38 +0000 Subject: [CMake] CMake misidentifies xlc++ as Clang Message-ID: <611396c23a5740c8bc83ec1eb5390913@lanl.gov> Hi, I am using cmake-3.9.4 on a power9 system with CXX=xlc++ (IBM XL C++) and CMake is misidentifying the compiler as "clang". % uname -a Linux cn2021 4.11.0-44.4.1.el7a.ppc64le #1 SMP Sat Dec 9 02:17:51 EST 2017 ppc64le ppc64le ppc64le GNU/Linux % echo $CXX xlc++ % $CXX --version IBM XL C/C++ for Linux, V13.1.6 (Community Edition) Version: 13.01.0006.0001 % cmake .. -- The CXX compiler identification is Clang 4.0.1 -- Check for working CXX compiler: /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ -- Check for working CXX compiler: /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ -- works ... Because, the compiler_ID is misidentified, inappropriate compiler options are added when CXX_CXX_STANDARD is set (along with other issues). Question 1: How do I report this as a bug? What additional information is needed to characterize the failure mode? Question 2: Is there a way to force the compiler ID to be "XL" as a temporary work around until the bug is fixed? Thank you, -kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikelojkovic at gmail.com Thu Mar 8 03:23:47 2018 From: mikelojkovic at gmail.com (mike lojkovic) Date: Thu, 8 Mar 2018 02:23:47 -0600 Subject: [CMake] GSOC 2018 CMake Project for Kodi In-Reply-To: References: Message-ID: Alright, signing up for a community college course does suffice. I'm definitely interested in this project. My actual computer is going to be down for at least a few more days. The damn thing sprung a leak, and Performance pcs is out of the right tubes. (using mobile for now) I should be back up and running by the end of the week. I'll get the formal application in around then. On Mar 7, 2018 5:52 AM, "Craig Scott" wrote: > You may want to have a look at the new FetchContent > module > added in the 3.11 release (currently in release candidate stage). It > already brings a production-tested dependency downloading system, but still > leaves how to build those dependencies up to the project. It may form a > good basis for the GSoC work and I can probably answer questions related to > that module if needed. > > Also consider other existing systems which may have already sufficiently > solved this problem for you or at least be useful for showing how aspects > of the work could be done. There are a number of popular systems worth > checking out that are often mentioned on this list, including hunter, > Spack, cget and others (I'll let the various stakeholders in the relevant > projects chime in with their views rather than me potentially misrepresent > some). > > > On Wed, Mar 7, 2018 at 7:57 PM, Kolja Lampe wrote: > >> Hey everybody, >> >> the Kodi Team is also offering a CMake related Project. >> Please check it out: >> >> *Description:* Kodi has its own system for building the many libraries >> Kodi depends on that supports most platforms (Linux, Android, OS X, iOS) >> and cross-compiling called depends. At the moment, it is implemented with >> autotools and hand-crafted Makefiles. This has lead to a lot of code >> duplication, poor maintainability, and not being very user-friendly. Also, >> it does not currently work on Windows. This task would be about replacing >> the current system with a new implementation in CMake that has better >> maintainability. >> >> *Expected outcome:* A CMake-based dependency build system that offers >> roughly the same features as depends (i.e. all required libraries covered, >> diverse platform support, crosscompilation). If the solution can also be >> applied to Windows by e.g. adding minimal CMake files to replace some >> UNIX-only build systems, that would be a big plus, but it is not necessary. >> >> *Skills preferred:* CMake, shell scripting, general familiarity with >> UNIX/Linux >> >> *Possible mentors:* wsnipex >> >> *Difficulty:* Medium >> >> *Type:* Infrastructure/Automation >> >> https://kodi.wiki/view/Google_Summer_of_Code/2018#Replacing_ >> depends_with_a_CMake-based_system >> >> Thanks! >> >> -- >> >> 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 >> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chad.s.gilbert at gmail.com Thu Mar 8 10:29:00 2018 From: chad.s.gilbert at gmail.com (Chad Gilbert) Date: Thu, 8 Mar 2018 11:29:00 -0400 Subject: [CMake] GoogleTest integration with CTest Message-ID: ?Hi all, I'm a new poster on this list. It's nice to meet you. ? I ? was very excited when I came across the new support for GoogleTest test discovery in CMake ( https://blog.kitware.com/dynamic-google-test-discovery-in-cmake-3-10/). However, this new approach and the older one both play very poorly with any of my tests that require fixtures. The situation I have is this: I have about a hundred tests defined which rely on a socket connection that has to pass a few messages each time it's initialized. I define a static test fixture in GoogleTest to make the connection to start the socket connection and initialize the server, then run all of the tests and clean up once when they're all done. The problem is that when I use `gtest_discover_tests()` (or `gtest_add_tests()`), CTest breaks all of the tests apart into separate processes, adding a couple seconds overhead to each test (the tests themselves take on average a millisecond to run). Perhaps that's still acceptable for now where I've only got ~100 tests that depend on that fixture, but I worry my list of tests will still grow, and it smells like that penalty should be avoidable somehow. I don't necessarily need to be able to see the output of every CTest (though that's a nice-to-have). What I really need is to be able to see all of the test results in my project CDash. Is there any way to have GoogleTest supply its own test results to CDash such that the GTest executable is only run once, but all of the individual test results can be reported? Thanks! Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Mar 8 11:17:35 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 8 Mar 2018 11:17:35 -0500 Subject: [CMake] CMake misidentifies xlc++ as Clang In-Reply-To: <611396c23a5740c8bc83ec1eb5390913@lanl.gov> References: <611396c23a5740c8bc83ec1eb5390913@lanl.gov> Message-ID: Hi. 1. You can report this issue on the CMake gitlab ( https://gitlab.kitware.com/cmake/cmake/issues ). You will want to attach the result of dumping all defines from the compiler ( xlc++ -dD -E - < /dev/null or xlc++ -dM -E ). Currently it looks like we are using '__IBMCPP__' to detect xlc++, and that might not be defined on the power pc platform. 2. If my guess about about 1 is correct, You can try setting the environment variable CXX_FLAGS to -qxlcompatmacros and see if that works ( https://www.ibm.com/support/knowledgecenter/SSXVZZ_13.1.3/com.ibm.xlcpp1313.lelinux.doc/compiler_ref/xlmacros.html#xlmacros__suplink1 ) On Wed, Mar 7, 2018 at 4:22 PM, Thompson, KT wrote: > Hi, > > > > I am using cmake-3.9.4 on a power9 system with CXX=xlc++ (IBM XL C++) and > CMake is misidentifying the compiler as "clang". > > > > % uname -a > > Linux cn2021 4.11.0-44.4.1.el7a.ppc64le #1 SMP Sat Dec 9 02:17:51 EST 2017 > ppc64le ppc64le ppc64le GNU/Linux > > > > % echo $CXX > > xlc++ > > > > % $CXX --version > > IBM XL C/C++ for Linux, V13.1.6 (Community Edition) > > Version: 13.01.0006.0001 > > > > % cmake .. > > -- The CXX compiler identification is Clang 4.0.1 > > -- Check for working CXX compiler: > /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ > > -- Check for working CXX compiler: > /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ -- works > > ? > > > > Because, the compiler_ID is misidentified, inappropriate compiler options > are added when CXX_CXX_STANDARD is set (along with other issues). > > > > Question 1: How do I report this as a bug? What additional information is > needed to characterize the failure mode? > > > > Question 2: Is there a way to force the compiler ID to be "XL" as a > temporary work around until the bug is fixed? > > > > Thank you, > > > > -kt > > > > > -- > > 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 > From irwin at beluga.phys.uvic.ca Thu Mar 8 13:50:13 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 8 Mar 2018 10:50:13 -0800 (PST) Subject: [CMake] What are the actual benefits of namespaced targets? Message-ID: I am currently trying to update three CMake-based build systems (for PLplot, ephcom, and te_gen) to use best practices following the really useful example of best practice given at . That example uses the NAMESPACE signature for the install(EXPORT ... ) command to export its targets. I realize that is a quite common practice, but I don't understand the motivation for this practice. After all, the library names (and therefore the un-namespaced associated targets) already are virtually guaranteed to be unique (since two projects with two different libraries with a common library name would be an invitation to nameclash disaster). So what are the actual benefits of namespacing the exported targets associated with libraries? The reason why I ask is namespaced targets would add some (small) complexity to my build systems. For example, I would need to define a namespaced ALIAS target for each library in my build tree to use common CMake logic to refer to that library in the build systems for both my build tree and install tree. (I use that common-code practice for all three of the above projects.) Defining such ALIAS targets should be absolutely straightforward, but I want to make sure the actual namespaced target benefits outweigh this small added complexity. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Thu Mar 8 14:05:48 2018 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 8 Mar 2018 20:05:48 +0100 Subject: [CMake] What are the actual benefits of namespaced targets? In-Reply-To: References: Message-ID: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> On 08.03.2018 19:50, Alan W. Irwin wrote: > So what are the actual benefits of namespacing the exported targets > associated with libraries? On the consumer side it makes linking to targets less error prone. When you link to a library target without a namespace and e.g. get the name or scope wrong CMake will silently assume that you want to link a library by name (e.g. in context of gcc "foo" becomes "-lfoo"). When the library and its headers happens to be in the compiler's standard search directories this might not even get caught at build time right away. When the library target has a namespace CMake will require the given name to be a target and will fail during generation if the target is not actually available. Nils From robert.maynard at kitware.com Thu Mar 8 14:44:01 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 8 Mar 2018 14:44:01 -0500 Subject: [CMake] CMake misidentifies xlc++ as Clang In-Reply-To: References: <611396c23a5740c8bc83ec1eb5390913@lanl.gov> Message-ID: Just to roundtrip this for posterity. The fix for incorrect identification of XLC will be in CMake 3.11.0-rc3 On Thu, Mar 8, 2018 at 11:17 AM, Robert Maynard wrote: > Hi. > > 1. You can report this issue on the CMake gitlab ( > https://gitlab.kitware.com/cmake/cmake/issues ). You will want to > attach the result of dumping all defines from the compiler ( xlc++ -dD > -E - < /dev/null or xlc++ -dM -E ). Currently it looks like we are > using '__IBMCPP__' to detect xlc++, and that might not be defined on > the power pc platform. > > 2. If my guess about about 1 is correct, You can try setting the > environment variable CXX_FLAGS to -qxlcompatmacros and see if that > works ( https://www.ibm.com/support/knowledgecenter/SSXVZZ_13.1.3/com.ibm.xlcpp1313.lelinux.doc/compiler_ref/xlmacros.html#xlmacros__suplink1 > ) > > On Wed, Mar 7, 2018 at 4:22 PM, Thompson, KT wrote: >> Hi, >> >> >> >> I am using cmake-3.9.4 on a power9 system with CXX=xlc++ (IBM XL C++) and >> CMake is misidentifying the compiler as "clang". >> >> >> >> % uname -a >> >> Linux cn2021 4.11.0-44.4.1.el7a.ppc64le #1 SMP Sat Dec 9 02:17:51 EST 2017 >> ppc64le ppc64le ppc64le GNU/Linux >> >> >> >> % echo $CXX >> >> xlc++ >> >> >> >> % $CXX --version >> >> IBM XL C/C++ for Linux, V13.1.6 (Community Edition) >> >> Version: 13.01.0006.0001 >> >> >> >> % cmake .. >> >> -- The CXX compiler identification is Clang 4.0.1 >> >> -- Check for working CXX compiler: >> /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ >> >> -- Check for working CXX compiler: >> /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ -- works >> >> ? >> >> >> >> Because, the compiler_ID is misidentified, inappropriate compiler options >> are added when CXX_CXX_STANDARD is set (along with other issues). >> >> >> >> Question 1: How do I report this as a bug? What additional information is >> needed to characterize the failure mode? >> >> >> >> Question 2: Is there a way to force the compiler ID to be "XL" as a >> temporary work around until the bug is fixed? >> >> >> >> Thank you, >> >> >> >> -kt >> >> >> >> >> -- >> >> 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 >> From irwin at beluga.phys.uvic.ca Thu Mar 8 15:49:28 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 8 Mar 2018 12:49:28 -0800 (PST) Subject: [CMake] What are the actual benefits of namespaced targets? In-Reply-To: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> References: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> Message-ID: On 2018-03-08 20:05+0100 Nils Gladitz wrote: > On 08.03.2018 19:50, Alan W. Irwin wrote: >> So what are the actual benefits of namespacing the exported targets >> associated with libraries? > > On the consumer side it makes linking to targets less error prone. > > When you link to a library target without a namespace and e.g. get the name > or scope wrong CMake will silently assume that you want to link a library by > name (e.g. in context of gcc "foo" becomes "-lfoo"). > When the library and its headers happens to be in the compiler's standard > search directories this might not even get caught at build time right away. > > When the library target has a namespace CMake will require the given name to > be a target and will fail during generation if the target is not actually > available. Hi Nils: Thanks for that explanation which convinced me this particular "best practice" is worth implementing along with the rest mentioned in . Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From john.frankish at outlook.com Fri Mar 9 00:40:47 2018 From: john.frankish at outlook.com (John Frankish) Date: Fri, 9 Mar 2018 05:40:47 +0000 Subject: [CMake] Compiling cmake-3.10.2 against ncursesw In-Reply-To: References: Message-ID: bump -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of John Frankish Sent: Monday, 05 March 2018 15:45 To: cmake at cmake.org Subject: [CMake] Compiling cmake-3.10.2 against ncursesw Hi, I've been trying to compile cmake-3.10.2 on a system that has only ncursesw using the ./bootstrap script. I could not find a way to tell ./bootstrap to use ncursesw, so I added the following to Modules/FindCurses.cmake set(CURSES_NEED_WIDE TRUE) ..this enables ./bootstrap to find libncursesw, but not libformw, so I also added: set(CURSES_FORM_LIBRARY "/usr/local/lib/libformw.so") ..and ./bootstrap completes successfully. However "make" fails when it cannot find form.h (even though it found /usr/local/include/ncursesw/ncurses.h). After symlinking /usr/local/include/ncursesw/form.h -> ../form.h, "make" completes successfully. Is there any easy way to use ./bootstrap on an ncursesw system? If Modules/FindCurses.cmake has the problems above when compiling cmake itself, won't it also have problems when compiling other stuff against ncursesw? Regards John -- 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 From nick at appletonaudio.com Fri Mar 9 00:23:33 2018 From: nick at appletonaudio.com (nick at appletonaudio.com) Date: Fri, 09 Mar 2018 16:23:33 +1100 Subject: [CMake] Mapping configurations and include_external_msproject() Message-ID: <63699f327a25aa44179cb15a05329f90@appletonaudio.com> Hi, I'm using CMake for a project which (on Windows) uses include_external_msproject() to import Visual Studio project files which were generated by another build system. These project files do not contain the usual "Debug" and "Release" configurations, but have a large set of configurations which map over a set of parameters. In my project, I would like to be able to say that my "Release" build corresponds to a "xxxx_yyy_release" variant of the sub-project. The old set of posts below appear to be asking for the same thing: https://cmake.org/pipermail/cmake/2016-February/062762.html Currently, I can't seem to find a way to do this. It looks like the MAP_IMPORTED_CONFIG_* variables are what I want, but it does not look like they work with include_external_msproject(). https://cmake.org/cmake/help/v3.9/prop_tgt/MAP_IMPORTED_CONFIG_CONFIG.html Does anyone have any advice? Thanks! Nick From seanga2 at gmail.com Fri Mar 9 01:14:55 2018 From: seanga2 at gmail.com (Sean Anderson) Date: Fri, 9 Mar 2018 01:14:55 -0500 Subject: [CMake] Specifying individual install locations at CPack time Message-ID: <8daa6e91-f251-f7dd-234a-49264163e4f8@gmail.com> Hi, I'm creating a small library (https://github.com/Forty-Bot/appdir) using CMake, and I would like to package it with CPack. I build a shared library, and some html documentation. In addition to that, I need to ship the headers, the README, and the license. If I were to make an archive by hand, it would look like libappdir.so appdir.h README.md COPYING.LESSER doc/ index.html ... However, when running `make install`, these files go in different locations (using GNUInstallDirs for the variables): ${CMAKE_INSTALL_LIBDIR}/ libappdir.so ${CMAKE_INSTALL_INCLUDEDIR}/ appdir.h ${CMAKE_INSTALL_DOCDIR}/ README.md COPYING.LESSER html/ index.html ... Of course, on Debian systems, `COPYING.LESSER` should be omitted, and a `copyright` file should be written referencing the copy of the LGPL in `/usr/share/common-licenses`, and this assumes some sort of posix-y system. On windows, I don't think it makes sense to support an install target because there is no standard location for dlls. On darwin, I have no idea what the standard is, but it's likely not what works for linux. Lastly, I'd like to generate reasonable output for DEB and RPM, as well as one of the macos installers. Clearly the default CPack behaviour will not work here. Currently, I use a variable `CREATE_ARCHIVE` to switch between install layout behaviour, but it seems like there should be some sort of way to do this without reconfiguring; after all, the only difference is where everything gets copied. I looked into using `CPACK_INSTALLED_DIRECTORIES`, but I want to control individual files, and I'd end up having to simulate an install step in order to get the correct directories. I also considered `CPACK_INSTALL_SCRIPT`, but it looked like I'd just end up writing my own `cmake_install.cmake`s. And of course, all of these solutions would need to use `CPACK_PROJECT_CONFIG_FILE` to detect what sort of build we were doing, which as far as I can tell corresponds to `CPACK_INCLUDE_TOPLEVEL_DIRECTORY`. This seems like a rather common use-case, and I'm surprised that I couldn't find any obvious solution for it. Am I missing something here? Installing everything twice and using components to select between configurations could work, but it would mess up invocations of `make install`. Additionally, my current solution doesn't address the installation of `copyright` for Debian (Somehow we need to detect whether we're on debian or whether we're build a deb). The GNUInstallDirs script seems to only be valid for posix-y systems. Is there some equivalent for discovering where to install things on (say) Darwin? I've been digging around for a few days, and there doesn't seem to be any prior work in this area (not to mention the paucity of documentation). Thanks in advance for any tips. --Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: OpenPGP digital signature URL: From mateusz at loskot.net Fri Mar 9 04:22:59 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri, 9 Mar 2018 10:22:59 +0100 Subject: [CMake] CMAKE_GENERATOR_INSTANCE with absolute path to Visual Studio instance Message-ID: Hi, I've just learned that CMake 3.11 solves the issue of selecting particular Visual Studio 2017 instance via CMAKE_GENERATOR_INSTANCE. This is good news and thank you for this improvement. I, however, am not entirely clear what the docs [2] mean by "The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance." Is this supposed to be set with one of installationPath values as by vswhere [3] C:\> vswhere -all -prerelease -property installationPath C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional [1] https://gitlab.kitware.com/cmake/cmake/commit/9ffb35386fb923a5959eec482bfa131aa3feaa18 [2] https://cmake.org/cmake/help/v3.11/generator/Visual Studio 15 2017.html [3] https://github.com/Microsoft/vswhere Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From robert.maynard at kitware.com Fri Mar 9 14:00:20 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 9 Mar 2018 14:00:20 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing Message-ID: I am proud to announce the third CMake 3.11 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc2: Brad King (3): XL: Recognize compilers identified by __ibmxl__ CUDA: Do not pass unsupported @rspfile arguments to NVCC CMake 3.11.0-rc3 KWSys Upstream (1): KWSys 2018-03-07 (2ad561e7) Sebastian Holtermann (1): Autogen: Check if a file is empty before reading it From ondrej at certik.us Fri Mar 9 19:58:42 2018 From: ondrej at certik.us (=?utf-8?Q?Ond=C5=99ej=20=C4=8Cert=C3=ADk?=) Date: Fri, 09 Mar 2018 17:58:42 -0700 Subject: [CMake] cmake thinks mingw-64 gfortran on Windows is broken Message-ID: <1520643522.131235.1297975256.06329515@webmail.messagingengine.com> Hi, I have previously reported the issue here: https://gitlab.kitware.com/cmake/cmake/issues/17810 I was told to follow https://blog.kitware.com/fortran-for-cc-developers-made-easier-with-cmake/. I did in fact follow it. Just to be sure, I tried the `-DCMAKE_GNUtoMS=ON -DBUILD_SHARED_LIBS=ON` with no difference. The problem is already at the "Check for working Fortran compiler" phase. As described in the issue above, CMake is trying to use gfortran for linking and passes incorrect options to it. My understanding is that on Windows, one must use gfortran to build a dll, and then dynamically link it with MSVC, with the proper cmake options like `-DCMAKE_GNUtoMS=ON -DBUILD_SHARED_LIBS=ON`. However, this can only be done once the "Check for working Fortran compiler" phase passes. How do I make CMake pass the "Check for working Fortran compiler" phase? Thanks, Ondrej From kai.wolf at gmail.com Sat Mar 10 04:03:14 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Sat, 10 Mar 2018 10:03:14 +0100 Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing In-Reply-To: References: Message-ID: Hey, it?s nice to see that we?re now able to set include directories and compiler flags for imported targets as well apparently. This means, no more add_library(foo UNKNOWN IMPORTED) set_target_properties(foo PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ? IMPORTED_LOCATION ..) but using target_* just like for any other target as well add_library(foo UNKNOWN IMPORTED) target_include_directories(foo PUBLIC ?) However, reading through the 3.11 documentation [1] I think I?ve found a bug unfortunately: "It is not possible to use an IMPORTED target in the left-hand-side of the target_compile_definitions(), target_include_directories(), target_compile_options() or target_link_libraries() commands, as that would be an attempt to modify it. IMPORTED targets are designed to be used only in the right-hand-side of those commands." If that?s really the case, I will submit a patch for it right away. I just want to make sure, I?m not misunderstanding something here? Greetings, Kai Wolf http://kai-wolf.me/ [1] https://cmake.org/cmake/help/v3.11/manual/cmake-buildsystem.7.html?highlight=right%20hand%20side#imported-targets > Am 09.03.2018 um 20:00 schrieb Robert Maynard : > > I am proud to announce the third CMake 3.11 release candidate. > https://cmake.org/download/ > > Documentation is available at: > https://cmake.org/cmake/help/v3.11 > > Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.11/release/3.11.html > > Some of the more significant changes in CMake 3.11 are: > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CMake 3.11 Release Notes > ************************ > > Changes made since CMake 3.10 include the following. > > > New Features > ============ > > > Platforms > --------- > > * TI C/C++ compilers are now supported by the "Ninja" generator. > > > Generators > ---------- > > * The "CodeBlocks" extra generator learned to check a > "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler > identification value to place in the project file. > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > > Commands > -------- > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" > and "NETRC_FILE" options to specify use of a ".netrc" file. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > > Variables > --------- > > * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the > selected instance of the generator's corresponding native tools if > multiple are available. This is used by the "Visual Studio 15 2017" > generator to hold the selected instance of Visual Studio > persistently. > > * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > to enable setting of default permissions for directories created > implicitly during installation of files by "install()" and > "file(INSTALL)", e.g. during "make install". > > * A "CMAKE_JOB_POOLS" variable was added specify a value to use for > the "JOB_POOLS" property. This enables control over build > parallelism with command line configuration parameters when using > the Ninja generator. > > * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to > specify use of a ".netrc" file by the "file(DOWNLOAD)" and > "file(UPLOAD)" commands and the "ExternalProject" module. > > * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to > initialize the "CUDA_SEPARABLE_COMPILATION" target property on > targets when they are created. > > > Properties > ---------- > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * An "IMPORTED_GLOBAL" target property was added to indicate whether > an IMPORTED target is globally visible. It is automatically set to a > true value for targets created with the "GLOBAL" option to > "add_library()" or "add_executable()". Additionally, project code > may now *promote* a local imported target to be globally visible by > setting this property to "TRUE". > > * An "INCLUDE_DIRECTORIES" source file property was added to specify > list of preprocessor include file search directories. > > * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and > "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of > ".hlsl" sources with Visual Studio Generators. > > > Modules > ------- > > * The "CheckIncludeFile" module "check_include_file" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro > learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "check_include_files" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command > gained a "LANGUAGE" option to specify whether to check using the "C" > or "CXX" compiler. > > * The "CMakePackageConfigHelpers" module > "write_basic_package_version_file()" command learned a new > "SameMinorVersion" mode for the "COMPATIBILITY" argument. > > * The "ExternalProject" module learned to substitute > "" in comments, commands, working directory and > byproducts. > > * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" > options to specify use of a ".netrc" file. > > * A new "FetchContent" module was added which supports populating > content at configure time using any of the download/update methods > supported by "ExternalProject_Add()". This allows the content to be > used immediately during the configure stage, such as with > "add_subdirectory()", etc. Hierarchical project structures are well > supported, allowing parent projects to override the content details > of child projects and ensuring content is not populated multiple > times throughout the whole project tree. > > * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME > "blis" and "libflame". > > * The "FindDoxygen" module "doxygen_add_docs()" function now > supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any > "DOXYGEN_..." variable contained in that list will bypass the > automatic quoting logic, leaving its contents untouched when > transferring them to the output "Doxyfile". > > * A "FindIconv" module was added to locate iconv support. > > * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command > gained an "INCLUDE_GUARD_NAME" option to change the name of the > include guard symbol written to the generated export header. > Additionally, it now adds a comment after the closing "#endif" on > the generated export header's include guard. > > * The "UseJava" module "add_jar" command gained a > "GENERATE_NATIVE_HEADERS" option to generate native header files > using "javac -h" for "javac" 1.8 or above. This supersedes > "create_javah", which no longer works with JDK 1.10 and above due to > removal of the "javah" tool by JEP 313. > > > Autogen > ------- > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CTest > ----- > > * The "ctest_start()" command no longer sets > "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is > called from inside a function. Instead, it sets an internal variable > in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the > global scope still prevents the script from being re-run at the end. > > > CPack > ----- > > * "cpack(1)" gained "--trace" and "--trace-expand" options. > > * The "CPackIFW" module gained new > "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the > target directory should not be deleted when uninstalling. > > * The "CPackRPM" module learned to enable enforcing of execute > privileges on programs and shared libraries. See > "CPACK_RPM_INSTALL_WITH_EXEC" variable. > > * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > which serves the same purpose during packaging (e.g. "make package") > as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves > during installation (e.g. "make install"). > > > Other > ----- > > * Alias Targets may now alias Imported Targets that are created with > the "GLOBAL" option to "add_library()". > > * Interface Libraries may now have custom properties set on them if > they start with either an underscore ("_") or a lowercase ASCII > character. The original intention was to only allow properties which > made sense for "INTERFACE" libraries, but it also blocked usage of > custom properties. > > * The "cmake(1)" "--open " command-line option was added to > open generated IDE projects like Visual Studio solutions or Xcode > projects. > > > Deprecated and Removed Features > =============================== > > * An explicit deprecation diagnostic was added for policies > "CMP0037" through "CMP0054" ("CMP0036" and below were already > deprecated). The "cmake-policies(7)" manual explains that the OLD > behaviors of all policies are deprecated and that projects should > port to the NEW behaviors. > > * The "KDevelop3" generator has been removed. > > > Other Changes > ============= > > * Policy "CMP0037" no longer reserves target names associated with > optional features, such as "test" and "package", unless the > corresponding feature is enabled. > > * The "FindOpenGL" module now prefers GLVND libraries if available. > See policy "CMP0072". > > * The minimum deployment target set in the > "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for > macOS regardless of the selected SDK. It is now properly set for > the target platform selected by "CMAKE_OSX_SYSROOT". For example, if > the sysroot variable specifies an iOS SDK then the value in > "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. > > * The "Xcode" generator behavior of generating one project file per > "project()" command may now be controlled with the > "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could > be useful to speed up the CMake generation step for large projects > and to work-around a bug in the "ZERO_CHECK" logic. > > * Since the "CMakeCache.txt" format does not support newlines in > values, values containing newlines are now truncated before writing > to the file. In addition, a warning comment is written to the cache > file, and a warning message is displayed to the user on the console. > > ---------------------------------------------------------------------------- > Changes made since CMake 3.11.0-rc2: > > Brad King (3): > XL: Recognize compilers identified by __ibmxl__ > CUDA: Do not pass unsupported @rspfile arguments to NVCC > CMake 3.11.0-rc3 > > KWSys Upstream (1): > KWSys 2018-03-07 (2ad561e7) > > Sebastian Holtermann (1): > Autogen: Check if a file is empty before reading it > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From robert.maynard at kitware.com Sat Mar 10 13:55:41 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Sat, 10 Mar 2018 13:55:41 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing In-Reply-To: References: Message-ID: You are correct the buildsystem documentation is out of date and now incorrect. So please submit patch. On Sat, Mar 10, 2018 at 4:03 AM, Kai Wolf wrote: > Hey, > > it?s nice to see that we?re now able to set include directories and compiler > flags for imported targets as well apparently. > This means, no more > > add_library(foo UNKNOWN IMPORTED) > set_target_properties(foo PROPERTIES > INTERFACE_INCLUDE_DIRECTORIES ? > IMPORTED_LOCATION ..) > > but using target_* just like for any other target as well > > add_library(foo UNKNOWN IMPORTED) > target_include_directories(foo PUBLIC ?) > > However, reading through the 3.11 documentation [1] I think I?ve found a bug > unfortunately: > > "It is not possible to use an IMPORTED target in the left-hand-side of the > target_compile_definitions(), target_include_directories(), > target_compile_options() or target_link_libraries() commands, as that would > be an attempt to modify it. IMPORTED targets are designed to be used only in > the right-hand-side of those commands." > > If that?s really the case, I will submit a patch for it right away. I just > want to make sure, I?m not misunderstanding something here? > > Greetings, > > Kai Wolf > http://kai-wolf.me/ > > [1] > https://cmake.org/cmake/help/v3.11/manual/cmake-buildsystem.7.html?highlight=right%20hand%20side#imported-targets > > Am 09.03.2018 um 20:00 schrieb Robert Maynard : > > I am proud to announce the third CMake 3.11 release candidate. > https://cmake.org/download/ > > Documentation is available at: > https://cmake.org/cmake/help/v3.11 > > Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.11/release/3.11.html > > Some of the more significant changes in CMake 3.11 are: > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CMake 3.11 Release Notes > ************************ > > Changes made since CMake 3.10 include the following. > > > New Features > ============ > > > Platforms > --------- > > * TI C/C++ compilers are now supported by the "Ninja" generator. > > > Generators > ---------- > > * The "CodeBlocks" extra generator learned to check a > "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler > identification value to place in the project file. > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > > Commands > -------- > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" > and "NETRC_FILE" options to specify use of a ".netrc" file. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > > Variables > --------- > > * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the > selected instance of the generator's corresponding native tools if > multiple are available. This is used by the "Visual Studio 15 2017" > generator to hold the selected instance of Visual Studio > persistently. > > * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > to enable setting of default permissions for directories created > implicitly during installation of files by "install()" and > "file(INSTALL)", e.g. during "make install". > > * A "CMAKE_JOB_POOLS" variable was added specify a value to use for > the "JOB_POOLS" property. This enables control over build > parallelism with command line configuration parameters when using > the Ninja generator. > > * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to > specify use of a ".netrc" file by the "file(DOWNLOAD)" and > "file(UPLOAD)" commands and the "ExternalProject" module. > > * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to > initialize the "CUDA_SEPARABLE_COMPILATION" target property on > targets when they are created. > > > Properties > ---------- > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * An "IMPORTED_GLOBAL" target property was added to indicate whether > an IMPORTED target is globally visible. It is automatically set to a > true value for targets created with the "GLOBAL" option to > "add_library()" or "add_executable()". Additionally, project code > may now *promote* a local imported target to be globally visible by > setting this property to "TRUE". > > * An "INCLUDE_DIRECTORIES" source file property was added to specify > list of preprocessor include file search directories. > > * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and > "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of > ".hlsl" sources with Visual Studio Generators. > > > Modules > ------- > > * The "CheckIncludeFile" module "check_include_file" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro > learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "check_include_files" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command > gained a "LANGUAGE" option to specify whether to check using the "C" > or "CXX" compiler. > > * The "CMakePackageConfigHelpers" module > "write_basic_package_version_file()" command learned a new > "SameMinorVersion" mode for the "COMPATIBILITY" argument. > > * The "ExternalProject" module learned to substitute > "" in comments, commands, working directory and > byproducts. > > * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" > options to specify use of a ".netrc" file. > > * A new "FetchContent" module was added which supports populating > content at configure time using any of the download/update methods > supported by "ExternalProject_Add()". This allows the content to be > used immediately during the configure stage, such as with > "add_subdirectory()", etc. Hierarchical project structures are well > supported, allowing parent projects to override the content details > of child projects and ensuring content is not populated multiple > times throughout the whole project tree. > > * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME > "blis" and "libflame". > > * The "FindDoxygen" module "doxygen_add_docs()" function now > supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any > "DOXYGEN_..." variable contained in that list will bypass the > automatic quoting logic, leaving its contents untouched when > transferring them to the output "Doxyfile". > > * A "FindIconv" module was added to locate iconv support. > > * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command > gained an "INCLUDE_GUARD_NAME" option to change the name of the > include guard symbol written to the generated export header. > Additionally, it now adds a comment after the closing "#endif" on > the generated export header's include guard. > > * The "UseJava" module "add_jar" command gained a > "GENERATE_NATIVE_HEADERS" option to generate native header files > using "javac -h" for "javac" 1.8 or above. This supersedes > "create_javah", which no longer works with JDK 1.10 and above due to > removal of the "javah" tool by JEP 313. > > > Autogen > ------- > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CTest > ----- > > * The "ctest_start()" command no longer sets > "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is > called from inside a function. Instead, it sets an internal variable > in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the > global scope still prevents the script from being re-run at the end. > > > CPack > ----- > > * "cpack(1)" gained "--trace" and "--trace-expand" options. > > * The "CPackIFW" module gained new > "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the > target directory should not be deleted when uninstalling. > > * The "CPackRPM" module learned to enable enforcing of execute > privileges on programs and shared libraries. See > "CPACK_RPM_INSTALL_WITH_EXEC" variable. > > * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > which serves the same purpose during packaging (e.g. "make package") > as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves > during installation (e.g. "make install"). > > > Other > ----- > > * Alias Targets may now alias Imported Targets that are created with > the "GLOBAL" option to "add_library()". > > * Interface Libraries may now have custom properties set on them if > they start with either an underscore ("_") or a lowercase ASCII > character. The original intention was to only allow properties which > made sense for "INTERFACE" libraries, but it also blocked usage of > custom properties. > > * The "cmake(1)" "--open " command-line option was added to > open generated IDE projects like Visual Studio solutions or Xcode > projects. > > > Deprecated and Removed Features > =============================== > > * An explicit deprecation diagnostic was added for policies > "CMP0037" through "CMP0054" ("CMP0036" and below were already > deprecated). The "cmake-policies(7)" manual explains that the OLD > behaviors of all policies are deprecated and that projects should > port to the NEW behaviors. > > * The "KDevelop3" generator has been removed. > > > Other Changes > ============= > > * Policy "CMP0037" no longer reserves target names associated with > optional features, such as "test" and "package", unless the > corresponding feature is enabled. > > * The "FindOpenGL" module now prefers GLVND libraries if available. > See policy "CMP0072". > > * The minimum deployment target set in the > "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for > macOS regardless of the selected SDK. It is now properly set for > the target platform selected by "CMAKE_OSX_SYSROOT". For example, if > the sysroot variable specifies an iOS SDK then the value in > "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. > > * The "Xcode" generator behavior of generating one project file per > "project()" command may now be controlled with the > "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could > be useful to speed up the CMake generation step for large projects > and to work-around a bug in the "ZERO_CHECK" logic. > > * Since the "CMakeCache.txt" format does not support newlines in > values, values containing newlines are now truncated before writing > to the file. In addition, a warning comment is written to the cache > file, and a warning message is displayed to the user on the console. > > ---------------------------------------------------------------------------- > Changes made since CMake 3.11.0-rc2: > > Brad King (3): > XL: Recognize compilers identified by __ibmxl__ > CUDA: Do not pass unsupported @rspfile arguments to NVCC > CMake 3.11.0-rc3 > > KWSys Upstream (1): > KWSys 2018-03-07 (2ad561e7) > > Sebastian Holtermann (1): > Autogen: Check if a file is empty before reading it > -- > > 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 > > From irwin at beluga.phys.uvic.ca Sat Mar 10 17:01:42 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 10 Mar 2018 14:01:42 -0800 (PST) Subject: [CMake] What are the actual benefits of namespaced targets? In-Reply-To: References: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> Message-ID: On 2018-03-08 12:49-0800 Alan W. Irwin wrote: > On 2018-03-08 20:05+0100 Nils Gladitz wrote: > >> On 08.03.2018 19:50, Alan W. Irwin wrote: >>> So what are the actual benefits of namespacing the exported targets >>> associated with libraries? >> >> On the consumer side it makes linking to targets less error prone. >> >> When you link to a library target without a namespace and e.g. get the name >> or scope wrong CMake will silently assume that you want to link a library >> by name (e.g. in context of gcc "foo" becomes "-lfoo"). >> When the library and its headers happens to be in the compiler's standard >> search directories this might not even get caught at build time right away. >> >> When the library target has a namespace CMake will require the given name >> to be a target and will fail during generation if the target is not >> actually available. > > Hi Nils: > > Thanks for that explanation which convinced me this particular "best > practice" is worth implementing along with the rest mentioned in > . Hi Nils: Here are some further questions about best practice with regard to namespaced targets. The three different build systems I am updating in this regard have some common CMake code between the build-tree and install-tree cases (to build examples and run various commands for the two cases) so for that common code I need to use a namespaced ALIAS library for the rather large number of libraries and modules (e.g., PLplot device driver dll's) that are built by those three projects in order for the namespaced targets to also be available in the build-tree case. But since I am already going to the trouble of creating those ALIAS libraries for each of my real libraries and modules, what is best practice for use of those ALIAS libraries and modules in the build tree? For example, should I just confine their use to common target_link_libraries and add_dependencies commands for the build-tree and install-tree cases? Or would you recommend I expand their use further for the build tree case alone? For example, would you recommend the following change: OLD method: add_library(a ...) add_executable(b ...) target_link_libraries(b a) NEW method (where would be one of PLPLOT::, EPHCOM::, or TE_GEN:: depending on project): add_library(a ...) add_library(a ALIAS a) add_executable(b ...) target_link_libraries(b a) ? This *could* be considered best practice since similar motivations apply ("a" could be the name of a system library so using a as a target_link_libraries item *could* find a build system bug (where some naive build system developer was happily referring to what he thought was an internal library when in fact the system version was being used because of some misspelling issue when creating the library.) But I think such misspelling issues would be quickly found for build systems in any case so my feeling is you will say this is "one step too far" since there is lots of editing involved (for all code, not just the common code) for very little added benefit. Anyhow, your thoughts would be appreciated for reasonable best practice limits on how far (if any) beyond the common code case you would go to convert an old project to use ALIAS libraries and modules in the build tree that have to be implemented in any case for CMake code that is common to both the build tree and install tree. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Sun Mar 11 05:15:21 2018 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 11 Mar 2018 10:15:21 +0100 Subject: [CMake] What are the actual benefits of namespaced targets? In-Reply-To: References: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> Message-ID: <054f2036-67c6-c9fd-94a0-1aedc29d9b6d@gmail.com> On 10.03.2018 23:01, Alan W. Irwin wrote: > Anyhow, your thoughts would be appreciated for reasonable best > practice limits on how far (if any) beyond the common code case you > would go to convert an old project to use > ALIAS libraries and modules in the build tree that have to be > implemented in any case for CMake code that is common to > both the build tree and install tree. Hello Alan, I agree with your assessments. Assuming a project that is highly structured through directory scopes I might consider the following. Any target is defined in exactly one directory scope. Any command that extends the definition of a target has to use the original target name and should be in the same directory scope. In all other directory scopes I'd consider consistent use of a target's alias. While it is less likely for a seasoned developer to trip over the interpretation ambiguity in link libraries (due to familiarity and the fact that they probably already tripped over this and know the symptoms) it might still be beneficial for new / casual contributors which as likely consumers might also already be familiar with the aliases. One minor additional benefit might be that you are also not allowed to modify the original target through an alias. As such this would prevent you (assuming you stick to the namespaced names) from modifying targets from within foreign scopes which I think is a good thing to enforce. Beyond that consumers might be looking at your code base for examples on how to use the libraries in their own code where consistency might be beneficial. It might also help (slightly) if you ever decided to split off parts of your project into new projects (which then would become consumers of the exported targets). Nils From cyril.boucher94260 at gmail.com Sun Mar 11 14:08:21 2018 From: cyril.boucher94260 at gmail.com (Cyril Boucher) Date: Sun, 11 Mar 2018 19:08:21 +0100 Subject: [CMake] Adding a reference to Windows Media Player library using CMake + CSharp support In-Reply-To: References: Message-ID: Hi all, I figured I would dig up this question as I found a decent solution to this issue. After having a look at how Microsoft Visual Studio is doing to include references to external libraries, I came to realise that it is using a tool called TlbImp, which is short for Type Library Importer. The solution is pretty simple from there: use TlbImp to generate a library that CSharp will be able to import and add it via CMake to the project. My code for Windows Media Player boils down to this: set(_outLib ${CMAKE_CURRENT_BINARY_DIR}/generated/Interop.WMPLib.dll) execute_process(COMMAND ${TLBIMP_EXECUTABLE} ${WMP_LIBRARY} /namespace:WMPLib /out:${_outLib} RESULT_VARIABLE tlbimp_result ERROR_FILE ${CMAKE_CURRENT_BINARY_DIR}/tlbimp_log.txt ) set_target_properties(myproject VS_DOTNET_REFERENCES "WMPLib" VS_DOTNET_REFERENCEPROP_WMPLib_TAG_HintPath "${_outLib}" ) And there you have it! If you would like to see it used in a project, I have just uploaded a small project to my github that uses just that: https://github.com/ cyrilBoucher/space-invaders Hope this helps! Cyril Boucher 2018-02-01 21:57 GMT+01:00 Cyril Boucher : > Hi all, > > I am trying to use CMake and the CSharp support for a small project of > mine but I cannot seem to find a way to add a reference to the Windows > Media Player library. One of the reason for that is that I need to link my > project to wmp.dll which then needs to generate Interop.WMPLib.dll and a > reference needs to be added with its path pointing to the latter library. > > Adding wmp.dll to my project is as simple as a target_link_libraries call > but this does not seem to trigger the whole generation and add reference > sort of process. > > Has anyone ever had an experience with adding such libraries? Is there > support for these scenarios? > > Thanks! > Cyril Boucher > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Sun Mar 11 16:16:18 2018 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Sun, 11 Mar 2018 21:16:18 +0100 Subject: [CMake] FindMPI & policy CMP0004 Message-ID: <7e24ca9a-2443-476d-b8b9-a5907a8d63fb@gmx.net> Dear all, recently, I got a problem with FindMPI on our HPC systems. With cmake 3.10.2, I get an error about policy CMP0004. And I cannot set it to OLD anymore. Is this intended? Exactly the same error, together with a patch, is described in the bugtracker https://public.kitware.com/Bug/view.php?id=11881 I cannot reproduce the error easiliy. On my home system, it works. But on the hpc system, mpicc -showme:link returns -L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl so, we have exactly one -Wl, part and libraries otherwise. It looks to me, that the patch from the bugtracker should avoid the problem. Can somebody confirm this finding? The problem gets even worse with newercmake versions. With cmake 3.9, I can set policy cmp0004 to OLD, so FindMPI remains usable. With newer cmake versions, ie. 3.10.2, the policy setting seems to get deprecated. So, the user won't get any way to use newer cmake with such a bug. What is the preferred way to resolve such an issue, when the policy setting is not allowed anymore? Regards, Andreas From craig.scott at crascit.com Sun Mar 11 18:07:00 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 12 Mar 2018 09:07:00 +1100 Subject: [CMake] FindMPI & policy CMP0004 In-Reply-To: <7e24ca9a-2443-476d-b8b9-a5907a8d63fb@gmx.net> References: <7e24ca9a-2443-476d-b8b9-a5907a8d63fb@gmx.net> Message-ID: This could be a case of needing to clear out an old CMake cache. That problem you mentioned was supposed to have been fixed already. You can find the updated discussion of the Mantis issue you linked to in gitlab here where someone else had a situation that sounds similar to yours. On Mon, Mar 12, 2018 at 7:16 AM, Andreas Naumann wrote: > Dear all, > > recently, I got a problem with FindMPI on our HPC systems. With cmake > 3.10.2, I get an error about policy CMP0004. And I cannot set it to OLD > anymore. Is this intended? > > Exactly the same error, together with a patch, is described in the > bugtracker https://public.kitware.com/Bug/view.php?id=11881 > > I cannot reproduce the error easiliy. On my home system, it works. But on > the hpc system, mpicc -showme:link returns > -L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl > -lutil -lm -ldl > > so, we have exactly one -Wl, part and libraries otherwise. It > looks to me, that the patch from the bugtracker should avoid the problem. > Can somebody confirm this finding? > > The problem gets even worse with newercmake versions. With cmake 3.9, I > can set policy cmp0004 to OLD, so FindMPI remains usable. With newer cmake > versions, ie. 3.10.2, the policy setting seems to get deprecated. So, the > user won't get any way to use newer cmake with such a bug. > > What is the preferred way to resolve such an issue, when the policy > setting is not allowed anymore? > > Regards, > Andreas > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Mar 11 20:02:17 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 12 Mar 2018 00:02:17 +0000 Subject: [CMake] How to link against projects added through FetchContent Message-ID: Hi, I would like to know how to use the FetchContent properly so that I can link against downloaded (CMake enabled) projects. I have looked at the CMake docs, which although are quite thorough, almost always fail to list a complete example which is incredibly crucial to get up and running quickly. With ExternalProject_Add, we use add_dependencies(...) but that doesn't seem to be the case for FetchContent. Since I can immediately call add_subdirectory(...), I assumed that I can simply link to the library. But that doesn't seem to do anything. Here's my CMakeLists.txt `````````````````````````````````````````````````````````````` cmake_minimum_required(VERSION 3.5) project(testProj) include(FetchContent) FetchContent_Declare( Catch2 GIT_REPOSITORY "https://github.com/catchorg/Catch2" TEST_COMMAND "" ) FetchContent_GetProperties(catch) if(NOT Catch2_POPULATED) FetchContent_Populate(Catch2) add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR}) endif() add_executable(testExe main.cpp) target_link_libraries(testExe Catch2) `````````````````````````````````````````````````````````````` CMake populates Catch2 with Catch2-NOTFOUND. So, my question is, how do I link against projects added through FetchContent? - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sun Mar 11 20:43:37 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 11 Mar 2018 17:43:37 -0700 (PDT) Subject: [CMake] What are the actual benefits of namespaced targets? In-Reply-To: <054f2036-67c6-c9fd-94a0-1aedc29d9b6d@gmail.com> References: <34ca488c-57c8-78d4-1d4a-842672f3c80b@gmail.com> <054f2036-67c6-c9fd-94a0-1aedc29d9b6d@gmail.com> Message-ID: On 2018-03-11 10:15+0100 Nils Gladitz wrote: > On 10.03.2018 23:01, Alan W. Irwin wrote: >> Anyhow, your thoughts would be appreciated for reasonable best >> practice limits on how far (if any) beyond the common code case you >> would go to convert an old project to use >> ALIAS libraries and modules in the build tree that have to be >> implemented in any case for CMake code that is common to >> both the build tree and install tree. > > > Hello Alan, > > I agree with your assessments. > > Assuming a project that is highly structured through directory scopes I might > consider the following. > > Any target is defined in exactly one directory scope. > Any command that extends the definition of a target has to use the original > target name and should be in the same directory scope. > > In all other directory scopes I'd consider consistent use of a target's > alias. Hi Nils: I think your suggestions prior to the last one above make perfect sense, and as far as I know my three projects already conform to them. But I have now considered your last suggestion (replacing read-only library and module targets in the build tree with the relevant namespaced target alias), but I have decided the cost/benefit ratio is too high in the PLplot case. The cost issue is PLplot has some 330 different build system files (those named "CMakeLists.txt", "*.cmake", or "*in") and something like 30 different library and module targets. An additional complication is all libraries include "plplot" in the target name (including our principal library whose target name is "plplot") but "plplot" also occurs in all sorts of other contexts in those 330 files. So making this change in the PLplot case would require a massive mentally concentrated editing exercise for what I think is a rather small and mostly stylistic benefit. So for PLplot I plan to limit use of namespaced targets to just the target_link_libraries and add_dependencies commands that are common to the build-tree and install-tree build systems. In contrast to the PLplot case, the costs of your last suggestion are much lower for the ephcom and te_gen cases (many fewer build-system files, libraries, and modules) so in those cases I might go all the way with converting the present read-only library and module targets with namespaced targets. And similarly when implementing new projects since the costs are even lower in those cases. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From saadrustam at gmail.com Sun Mar 11 20:52:28 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 12 Mar 2018 00:52:28 +0000 Subject: [CMake] How to link against projects added through FetchContent In-Reply-To: References: Message-ID: I managed to find a solution myself: `````````````````````````````````````````````````````````````` cmake_minimum_required(VERSION 3.11) project(testProj) include(FetchContent) FetchContent_Declare( Catch2 GIT_REPOSITORY "https://github.com/catchorg/Catch2" ) FetchContent_GetProperties(Catch2) #mispelled name in original post if(NOT Catch2_POPULATED) FetchContent_Populate(Catch2) message(STATUS "Catch source dir: ${catch2_SOURCE_DIR}") message(STATUS "Catch binary dir: ${catch2_BINARY_DIR}") add_subdirectory(${catch2_SOURCE_DIR} ${catch2_BINARY_DIR}) #can be case insensitive endif() add_executable(testExe main.cpp ) message(STATUS "Catch include dir: ${catch2_SOURCE_DIR}/include") target_link_libraries(testExe Catch) #name of library to link is case sensitive! `````````````````````````````````````````````````````````````` On Sun, Mar 11, 2018 at 8:02 PM Saad Khattak wrote: > Hi, > > I would like to know how to use the FetchContent properly so that I can > link against downloaded (CMake enabled) projects. I have looked at the > CMake docs, which although are quite thorough, almost always fail to list a > complete example which is incredibly crucial to get up and running quickly. > > With ExternalProject_Add, we use add_dependencies(...) but that doesn't > seem to be the case for FetchContent. Since I can immediately call > add_subdirectory(...), I assumed that I can simply link to the library. But > that doesn't seem to do anything. > > Here's my CMakeLists.txt > `````````````````````````````````````````````````````````````` > cmake_minimum_required(VERSION 3.5) > project(testProj) > > include(FetchContent) > > FetchContent_Declare( > Catch2 > GIT_REPOSITORY "https://github.com/catchorg/Catch2" > TEST_COMMAND "" > ) > > FetchContent_GetProperties(catch) > if(NOT Catch2_POPULATED) > FetchContent_Populate(Catch2) > add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR}) > endif() > > add_executable(testExe main.cpp) > > target_link_libraries(testExe Catch2) > `````````````````````````````````````````````````````````````` > > CMake populates Catch2 with Catch2-NOTFOUND. > > So, my question is, how do I link against projects added through > FetchContent? > > - Saad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Mar 11 20:55:18 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 12 Mar 2018 11:55:18 +1100 Subject: [CMake] How to link against projects added through FetchContent In-Reply-To: References: Message-ID: Thanks for trying out the new FetchContent module. Comments on your question interspersed below. On Mon, Mar 12, 2018 at 11:02 AM, Saad Khattak wrote: > Hi, > > I would like to know how to use the FetchContent properly so that I can > link against downloaded (CMake enabled) projects. I have looked at the > CMake docs, which although are quite thorough, almost always fail to list a > complete example which is incredibly crucial to get up and running quickly. > > With ExternalProject_Add, we use add_dependencies(...) but that doesn't > seem to be the case for FetchContent. Since I can immediately call > add_subdirectory(...), I assumed that I can simply link to the library. But > that doesn't seem to do anything. > This is indeed how it should work. After you've called add_subdirectory(), the targets defined by the project being added should be immediately available just like any other target your own project would define. > > Here's my CMakeLists.txt > `````````````````````````````````````````````````````````````` > cmake_minimum_required(VERSION 3.5) > Your minimum CMake version will be 3.11 if you want to use FetchContent, so consider specifying that as the minimum version here. > project(testProj) > > include(FetchContent) > > FetchContent_Declare( > Catch2 > GIT_REPOSITORY "https://github.com/catchorg/Catch2" > TEST_COMMAND "" > ) > As stated in the docs, TEST_COMMAND will be ignored, so don't set it here. FetchContent only downloads, it doesn't build (you're in control of that, see further comments below). The ExternalProject_Add() docs also recommend you set GIT_TAG to the specific git hash you want to use (apart from being more robust, it saves having to contact the remote each time CMake is run after it has been cloned). FetchContent delegates all downloading to ExternalProject, so the comments apply here as well. > > FetchContent_GetProperties(catch) > This needs to be the same as the first argument to FetchContent_Declare() above, i.e. Catch2 > if(NOT Catch2_POPULATED) > FetchContent_Populate(Catch2) > add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR}) > The documentation for the FetchContent_Populate() function state that the variable names use lowercased names of the content name (i.e. catch2_SOURCE_DIR rather than Catch2_SOURCE_DIR), so both of these variables used here will be empty. I'm a little surprised CMake didn't complain about that, it does for me when I tested this just now. Same for the variable name used in the if test (i.e. use catch2_POPULATED rather than Catch2_POPULATED). The reason for the lowercasing is that it was found during the 2 years or so when we were dog-fooding this module that while people usually got the name right, there would be variations in upper/lowercase which made things less reliable. > endif() > > add_executable(testExe main.cpp) > > target_link_libraries(testExe Catch2) > If the Catch2 project defines a library called Catch2, then this line should work fine once you fix the above problems. I think you want Catch rather than Catch2 though. > `````````````````````````````````````````````````````````````` > > CMake populates Catch2 with Catch2-NOTFOUND. > > So, my question is, how do I link against projects added through > FetchContent? > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Mar 11 21:17:54 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 12 Mar 2018 01:17:54 +0000 Subject: [CMake] How to link against projects added through FetchContent In-Reply-To: References: Message-ID: Thank you for the clarifications Craig! The confusion mainly stemmed from ${Catch2_SOURCE_DIR} where 'Catch2' should have been lowercase. I had originally started with the name 'catch' (which would explain why I accidentally left it unchanged in the _GetProperties function) but when that didn't work, I started assuming that perhaps it was conflicting with the actual library. It was all downhill from there :) After your suggestions, I was successfully able to get it to work. For future reference for anyone stumbling on this answer, here's a minimum example of a working version: https://github.com/samaursa/cmake_fetch_content >> I'm a little surprised CMake didn't complain about that, it does for me when I tested this just now CMake did not warn me about it. I am on CMake Version 3.11.0-rc3. It would be great if this warning could be emphasized by CMake as without it, it is difficult to tell what went wrong since `target_link_libraries` also fails and I simply get compile errors for missing headers. On Sun, Mar 11, 2018 at 8:55 PM Craig Scott wrote: > Thanks for trying out the new FetchContent module. Comments on your > question interspersed below. > > > On Mon, Mar 12, 2018 at 11:02 AM, Saad Khattak > wrote: > >> Hi, >> >> I would like to know how to use the FetchContent properly so that I can >> link against downloaded (CMake enabled) projects. I have looked at the >> CMake docs, which although are quite thorough, almost always fail to list a >> complete example which is incredibly crucial to get up and running quickly. >> >> With ExternalProject_Add, we use add_dependencies(...) but that doesn't >> seem to be the case for FetchContent. Since I can immediately call >> add_subdirectory(...), I assumed that I can simply link to the library. But >> that doesn't seem to do anything. >> > > This is indeed how it should work. After you've called add_subdirectory(), > the targets defined by the project being added should be immediately > available just like any other target your own project would define. > > > >> >> Here's my CMakeLists.txt >> `````````````````````````````````````````````````````````````` >> cmake_minimum_required(VERSION 3.5) >> > > Your minimum CMake version will be 3.11 if you want to use FetchContent, > so consider specifying that as the minimum version here. > > > > >> project(testProj) >> >> include(FetchContent) >> >> FetchContent_Declare( >> Catch2 >> GIT_REPOSITORY "https://github.com/catchorg/Catch2" >> TEST_COMMAND "" >> ) >> > > As stated in the docs, TEST_COMMAND will be ignored, so don't set it here. > FetchContent only downloads, it doesn't build (you're in control of that, > see further comments below). The ExternalProject_Add() docs also recommend > you set GIT_TAG to the specific git hash you want to use (apart from being > more robust, it saves having to contact the remote each time CMake is run > after it has been cloned). FetchContent delegates all downloading to > ExternalProject, so the comments apply here as well. > > > >> >> FetchContent_GetProperties(catch) >> > > This needs to be the same as the first argument to FetchContent_Declare() > above, i.e. Catch2 > > >> if(NOT Catch2_POPULATED) >> FetchContent_Populate(Catch2) >> add_subdirectory(${Catch2_SOURCE_DIR} ${Catch2_BINARY_DIR}) >> > > The documentation for the FetchContent_Populate() function state that the > variable names use lowercased names of the content name (i.e. > catch2_SOURCE_DIR rather than Catch2_SOURCE_DIR), so both of these > variables used here will be empty. I'm a little surprised CMake didn't > complain about that, it does for me when I tested this just now. Same for > the variable name used in the if test (i.e. use catch2_POPULATED rather > than Catch2_POPULATED). > > The reason for the lowercasing is that it was found during the 2 years or > so when we were dog-fooding this module that while people usually got the > name right, there would be variations in upper/lowercase which made things > less reliable. > > > >> endif() >> >> add_executable(testExe main.cpp) >> >> target_link_libraries(testExe Catch2) >> > > If the Catch2 project defines a library called Catch2, then this line > should work fine once you fix the above problems. I think you want Catch > rather than Catch2 though. > > > > >> `````````````````````````````````````````````````````````````` >> >> CMake populates Catch2 with Catch2-NOTFOUND. >> >> So, my question is, how do I link against projects added through >> FetchContent? >> > > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Sun Mar 11 23:10:59 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Sun, 11 Mar 2018 20:10:59 -0700 Subject: [CMake] Modern CMake + CUDA + Clang Message-ID: <2049DE89-2137-497D-B0F1-23D87EE99576@cornell.edu> Hello! I stumbled across the new 3.8+ CUDA as a language capabilities, and am very excited about this! 1. Does anybody know when CMAKE_CUDA_COMPILER_ID and CMAKE_CUDA_COMPILER_VERSION were fixed? With cmake 3.9.4 some of the cuda compiler variables were unset: message("CXX compiler stuff:") message(STATUS "CMAKE_CXX_COMPILER: ${CMAKE_CXX_COMPILER}") message(STATUS "CMAKE_CXX_COMPILER_ID: ${CMAKE_CXX_COMPILER_ID}") message(STATUS "CMAKE_CXX_COMPILER_VERSION: ${CMAKE_CXX_COMPILER_VERSION}") message("CUDA compiler stuff:") message(STATUS "CMAKE_CUDA_COMPILER: ${CMAKE_CUDA_COMPILER}") message(STATUS "CMAKE_CUDA_COMPILER_ID: ${CMAKE_CUDA_COMPILER_ID}") message(STATUS "CMAKE_CUDA_COMPILER_VERSION: ${CMAKE_CUDA_COMPILER_VERSION}") message(FATAL_ERROR "bye bye") CMAKE_CUDA_COMPILER was set, but COMPILER_ID and COMPILER_VERSION were not. I just updated to 3.10.2 and they were giving values I would expect. I dug around under the diffs on Modules but got really turned around. I would like to set my minimum required version to whenever this was introduced, as I would like to wield it. 2. Is there any existing work / discussion on the new world order (CUDA as a full-fledged language) and Clang? I noticed that the following happens: if(CMAKE_CUDA_COMPILER_ID) include(Compiler/${CMAKE_CUDA_COMPILER_ID}-CUDA OPTIONAL) endif() leaving room for a Compiler/Clang-CUDA.cmake to be created. Is there an eventual goal to write this? I think I can maybe help get a prototype working if that was the goal for this setup. 3. Supposing CMake + Clang + CUDA was working, the working assumption would be that a user sets CUDACXX to clang++, right? I?m trying to understand if Clang as a cuda compiler already works and I have bad local configurations, or if they are needing to be written. Thanks for any thoughts! -Stephen From ewmailing at gmail.com Mon Mar 12 00:13:03 2018 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 11 Mar 2018 21:13:03 -0700 Subject: [CMake] Swift Makefile/Ninja generator: trying to bring up to date Message-ID: Hi, I know it?s been awhile since I last posted anything about this. Since my last post, I had quietly added to the Ninja backend to bring it to par with the initial work I did on the Makefile generator. This was partly done because I was trying to get compatibility with Android which uses the CMake/Ninja generator. Anyway, the CMake/Android support has come a long way in the past year. I see that there is now even a way to specify an external CMake in local.properties as long as it is 3.7 (or greater I presume). I really need to be leveraging all the new support in Android Studio, so I need to update my version of CMake. Unfortunately, my Swift work started before 3.7, and I just tried a merge with the latest, but the merge went very badly. It looks like cmLocalGenerator.cxx has been significantly rewritten in passing time, and I am no longer certain how to integrate my original changes. Can some of you CMake guru?s clue me in on how I should change my original patch to now work with the current CMake source? Is cmLocalGenerator.cxx my only problem, or are there other architectural changes I need to be aware of to make all the other changes in other files also work? There are 10 small commits I made in a separate branch for my original change, which can be seen at the top of the page at GitHub: https://github.com/ewmailing/CMake/commits/SwiftMakefile Thanks, Eric From sjm324 at cornell.edu Mon Mar 12 00:58:49 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Sun, 11 Mar 2018 21:58:49 -0700 Subject: [CMake] Modern CMake + CUDA + Clang In-Reply-To: <2049DE89-2137-497D-B0F1-23D87EE99576@cornell.edu> References: <2049DE89-2137-497D-B0F1-23D87EE99576@cornell.edu> Message-ID: I found the GitLab tracker: https://gitlab.kitware.com/cmake/cmake/issues/16586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Mon Mar 12 03:15:50 2018 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Mon, 12 Mar 2018 08:15:50 +0100 Subject: [CMake] FindMPI & policy CMP0004 In-Reply-To: References: <7e24ca9a-2443-476d-b8b9-a5907a8d63fb@gmx.net> Message-ID: Thank you for the hint, and I run in a similiar problem. Building from scratch solved the issue. Sorry for the noise. Am 11.03.2018 um 23:07 schrieb Craig Scott: > This could be a case of needing to clear out an old CMake cache. That > problem you mentioned was supposed to have been fixed already. You can > find the updated discussion of the Mantis issue you linked to in > gitlab here > where someone > else had a situation that sounds similar to yours. > > > On Mon, Mar 12, 2018 at 7:16 AM, Andreas Naumann > > wrote: > > Dear all, > > recently, I got a problem with FindMPI on our HPC systems. With > cmake 3.10.2, I get an error about policy CMP0004. And I cannot > set it to OLD anymore. Is this intended? > > Exactly the same error, together with a patch, is described in the > bugtracker https://public.kitware.com/Bug/view.php?id=11881 > > > I cannot reproduce the error easiliy. On my home system, it works. > But on the hpc system, mpicc -showme:link returns > -L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt > -lnsl -lutil -lm -ldl > > so, we have exactly one -Wl, part and libraries > otherwise. It looks to me, that the patch from the bugtracker > should avoid the problem. > Can somebody confirm this finding? > > The problem gets even worse with newercmake versions. With cmake > 3.9, I can set policy cmp0004 to OLD, so FindMPI remains usable. > With newer cmake versions, ie. 3.10.2, the policy setting seems > to get deprecated. So, the user won't get any way to use newer > cmake with such a bug. > > What is the preferred way to resolve such an issue, when the > policy setting is not allowed anymore? > > Regards, > Andreas > -- > > 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 > > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com From brad.king at kitware.com Mon Mar 12 07:58:25 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Mar 2018 07:58:25 -0400 Subject: [CMake] cmake thinks mingw-64 gfortran on Windows is broken In-Reply-To: <1520643522.131235.1297975256.06329515@webmail.messagingengine.com> References: <1520643522.131235.1297975256.06329515@webmail.messagingengine.com> Message-ID: <388ed96a-418a-4522-235b-f859ef4c9625@kitware.com> On 03/09/2018 07:58 PM, Ond?ej ?ert?k wrote: > How do I make CMake pass the "Check for working Fortran compiler" phase? The problem reported in issue 17810 is caused by trying to enable C with MSVC and Fortran with GNU together at the same time, e.g. `project(MyProj C Fortran)`. These tools cannot be used together directly. The purpose of cmake_add_fortran_subdirectory as described in the blog post is to avoid enabling Fortran in the main project. Instead Fortran is only enabled in a separate project by itself, and the main project gets only C (and CXX). If you want to use MSVC and Fortran together directly then you need a Fortran compiler that works with the MSVC binutils. The Intel Fortran compiler for Windows, a commercial tool, is one option. There is also https://github.com/flang-compiler/flang, which is currently maturing. Alternatively you can use GNU from MinGW for all languages, e.g. `CC=gcc CXX=g++ FC=gfortran cmake ../src`. -Brad From cameron at promon.no Mon Mar 12 09:31:20 2018 From: cameron at promon.no (Cameron Palmer) Date: Mon, 12 Mar 2018 13:31:20 +0000 Subject: [CMake] Bitcode and CMake Message-ID: I?m building frameworks for iOS/tvOS with bitcode at the command-line. In order to compile and link I need to add two things: target_compile_options( library PUBLIC -fembed-bitcode ) target_link_libraries( library PUBLIC -fembed-bitcode ) This works, but yields the complaint that: ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) Is there a cleaner way to do this, or do I need to hammer header pad_max_install_names in CMAKE_CXX_LINK_FLAGS? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cameron at promon.no Mon Mar 12 10:36:08 2018 From: cameron at promon.no (Cameron Palmer) Date: Mon, 12 Mar 2018 14:36:08 +0000 Subject: [CMake] Cmake Frameworks and Bitcode Message-ID: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> So after a bit of hacking it seems that Cmake should provide something like: CMAKE_OSX_BITCODE_ENABLE Which would pass -fembed-bitcode to the compiler and linker and remove the option in Darwin.cmake for -Wl,-headerpad_max_install_names in CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS. Does this sound like something that should be submitted as a patch? From rcdailey.lists at gmail.com Mon Mar 12 16:03:30 2018 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 12 Mar 2018 15:03:30 -0500 Subject: [CMake] How to obtain a list of target dependencies Message-ID: Sometimes I need to manually take action on the dependencies of my targets. Without keeping track of the dependencies externally using global or custom target properties, is there a way to obtain the list of targets that a target depends on? This would be the same list of targets passed to `target_link_libraries()`. For bonus points I'd like a flattened list of transitive dependencies, to avoid recursively building this list myself. From rcdailey.lists at gmail.com Mon Mar 12 16:11:28 2018 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 12 Mar 2018 15:11:28 -0500 Subject: [CMake] How to obtain a list of target dependencies In-Reply-To: References: Message-ID: I'm going to add the CMake Dev group as well, since I asked this same question last year around May and I didn't get any response. Hoping for some help this time around. I don't see anything documented, so maybe the developers know the best approach here. On Mon, Mar 12, 2018 at 3:03 PM, Robert Dailey wrote: > Sometimes I need to manually take action on the dependencies of my > targets. Without keeping track of the dependencies externally using > global or custom target properties, is there a way to obtain the list > of targets that a target depends on? This would be the same list of > targets passed to `target_link_libraries()`. For bonus points I'd like > a flattened list of transitive dependencies, to avoid recursively > building this list myself. From ben.boeckel at kitware.com Mon Mar 12 16:39:53 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 12 Mar 2018 16:39:53 -0400 Subject: [CMake] [cmake-developers] How to obtain a list of target dependencies In-Reply-To: References: Message-ID: <20180312203953.GA20978@megas.kitware.com> On Mon, Mar 12, 2018 at 15:11:28 -0500, Robert Dailey wrote: > I'm going to add the CMake Dev group as well, since I asked this same > question last year around May and I didn't get any response. Hoping > for some help this time around. I don't see anything documented, so > maybe the developers know the best approach here. There's an issue for this here: https://gitlab.kitware.com/cmake/cmake/issues/12435 There has been extensive discussion on the feature and previous mailing list threads about it. I'm not intimately familiar with that discussion myself, but it has more details at least. --Ben From davidhuzj at gmail.com Tue Mar 13 02:34:23 2018 From: davidhuzj at gmail.com (Ziji Hu) Date: Tue, 13 Mar 2018 14:34:23 +0800 Subject: [CMake] Cannot build sub-directory library if top-level CMakeLists.txt call install(EXPORT ...) Message-ID: Hi all, I'm a newbie of CMake. I'm trying to add a feature as a sub-library to an existing application. But I met troubles of install(EXPORT ...) My project source code structure shows as below: app (the existing application) |-- top-level CMakeLists.txt | |-- sublib (my new feature) | |-- src | |-- include | |-- CMakeLists.txt | |-- other existing src ... I build sublib in the CMakeLists.txt inside my own feature as: ... add_library(sublib ${LIB_SRC}) ... I modify the top-level CMakeLists.txt in the existing application to link sublib: ... add_subdirectory(subdirectory of sublib) ... target_link_directories(app sublib) ... I thought it is enough. But CMake threw out an error: CMake Error: install(EXPORT "appTargets" ...) includes target "app" which requires target "sublib" that is not in the export set. I guess it is because "app" is exported by install(EXPORT .. ) in the top-level CMakeLists.txt. Thus I also install and export sublib. I add the install and export into sublib CMakeLists.txt: ... install(TARGETS sublib EXPORT sublibTargets ARCHIVE DESTINATION ${BIN_INSTALL_DIR} LIBRARY DESTINATION ${LIB_INSTALL_DIR} RUNTIME DESTINATION ${LIB_INSTALL_DIR} ) install(EXPORT sublibTargets FILE sublib-config.cmake DESTINATION ${LIB_INSTALL_DIR}/cmake/sublib ) ... I also add find_package() in top-level CMakeLists.txt: ... find_package(sublib REQUIRED) target_link_directories(app sublib) ... However, it becomes worse. sublib is not built at all and sublib-config.cmake is not found. Could you please tell me how fix the EXPORT issue? Thank you. Best regards, David Hu From sjm324 at cornell.edu Tue Mar 13 16:15:10 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Tue, 13 Mar 2018 13:15:10 -0700 Subject: [CMake] Modern CMake + CUDA + Clang In-Reply-To: References: <2049DE89-2137-497D-B0F1-23D87EE99576@cornell.edu> Message-ID: <867A63E5-8527-4831-948E-D52161C12FA6@cornell.edu> Excellent, this is very useful ? thanks Robert! I think I have some answers to some of these, but as I make progress will probably reach out to the LLVM mailing lists for help / suggestions (particularly with separable compilation and device linking). I?m still ramping up to speed on developing CMake. You had mentioned CMake_TEST_CUDA which will be helpful down the line, but intermediately is it ?ok? to just modify *.cmake modules in-place underneath the installed Modules and Modules/Compiler directories? I?ve got a custom install / am not concerned about breaking things in it, I?m just wondering if this is a typical practice or if I should be re-compiling and re-installing every time I make changes. From sjm324 at cornell.edu Tue Mar 13 16:18:30 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Tue, 13 Mar 2018 13:18:30 -0700 Subject: [CMake] Modern CMake + CUDA + Clang In-Reply-To: <867A63E5-8527-4831-948E-D52161C12FA6@cornell.edu> References: <2049DE89-2137-497D-B0F1-23D87EE99576@cornell.edu> <867A63E5-8527-4831-948E-D52161C12FA6@cornell.edu> Message-ID: <3A9871DD-88B7-4E91-8BBE-A98C8EAB16CC@cornell.edu> Whoops? sorry I replied to the mail server, please ignore this thread and let it die, see issue tracker linked in second post. From brad.king at kitware.com Wed Mar 14 14:32:50 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 14 Mar 2018 14:32:50 -0400 Subject: [CMake] Swift Makefile/Ninja generator: trying to bring up to date In-Reply-To: References: Message-ID: On 03/12/2018 12:13 AM, Eric Wing wrote: > There are 10 small commits I made in a separate branch for my original > change, which can be seen at the top of the page at GitHub: > https://github.com/ewmailing/CMake/commits/SwiftMakefile As of commit 6c296b3e208dbb4319f396fdfb751206cff1abe0 on that branch, your topic is based on a version of CMake `master` from Jan 2016. A lot of major refactoring has been done since then, including some migration toward cmState in an effort to separate the codemodel representation from the CMake language and the generators. Your patches don't look too big. You'll just have to find the new places for them. -Brad From neytra02 at yahoo.com Wed Mar 14 18:12:18 2018 From: neytra02 at yahoo.com (Tettey Nartey) Date: Wed, 14 Mar 2018 22:12:18 +0000 (UTC) Subject: [CMake] CMAKE References: <163176349.478402.1521065538972.ref@mail.yahoo.com> Message-ID: <163176349.478402.1521065538972@mail.yahoo.com> I am not entirely sure if I am reaching the right department that receives questions from mailing list subscribers. My situation really isn't that complicated, but I myself am troubled by it. I have a 64 bit Operating system, and I am need to use CMAKE with the CMAKE build files of GLFW. I would like to know if there is anything wrong with installing both 32 and 64 bit versions of the CMAKE installer? ?Also, if I am to download the GLFW source package containing the complete source code, does this mean I won't need to download the pre-compiled source binaries? Somewhere along the process of setting this all up, I got lost of track between distinguishing whether I am downloading for a platform I am making an application for, or for the system I am currently using to make the application. Sincerely,Tettey Nartey -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshuabaergen at gmail.com Wed Mar 14 23:18:31 2018 From: joshuabaergen at gmail.com (Joshua Baergen) Date: Thu, 15 Mar 2018 03:18:31 +0000 Subject: [CMake] Link-Time Dependency Injection for Unit Tests Message-ID: Hello, I'm attempting to implement link-time dependency injection. In brief, what this means is that, for a library A that depends on B, we would normally have: target_link_libraries(A B) However, when building unittests for A (done in a subdirectory), we instead want: target_link_libraries(A MockB) I've spent a bunch of time looking through CMake documentation and I'm not sure how to express this without resorting to manually specifying the link line when A is in use. Could someone give me some guidance? Thanks! Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Mar 15 04:56:20 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 15 Mar 2018 09:56:20 +0100 Subject: [CMake] Link-Time Dependency Injection for Unit Tests In-Reply-To: References: Message-ID: Hi Joshua, 2018-03-15 4:18 GMT+01:00 Joshua Baergen : > Hello, > > I'm attempting to implement link-time dependency injection. In brief, what > this means is that, for a library A that depends on B, we would normally > have: > > target_link_libraries(A B) > > However, when building unittests for A (done in a subdirectory), we > instead want: > > target_link_libraries(A MockB) > > I've spent a bunch of time looking through CMake documentation and I'm not > sure how to express this without resorting to manually specifying the link > line when A is in use. Could someone give me some guidance? > Since you want link-time choice I bet you should have a look to some kind of generator expression see doc here: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html genex may be used in target_link_libraries. for example if you can set some property on (all) your unit test target (I personnally do that globally by defining my own mytest_add_executable macro) set_target_properties( PROPERTIES UNITTEST 1) then may be you can use some genex which check whether an executable if a unitest: set(GenEx_IsTest $,1>) and then use some other genex using the previous one in target_link_libraries like here for automatic instantiation of source: https://cmake.org/pipermail/cmake/2015-January/059669.html I lack time to craft the complete example but I think it's doable with genex. It seems that others already played along this line: https://developer.blender.org/T46725 -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Mar 15 06:10:55 2018 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 15 Mar 2018 11:10:55 +0100 Subject: [CMake] Incremental builds with ExternalProject_Add Message-ID: Dear All, I ran into an issue with incremental builds that use ExternalProject_Add(...), which I'm very surprised isn't a more widely advertised issue. So I thought I'd ask here if people are aware of this behaviour... For our software projects we build a good number of externals using separate "externals project". https://gitlab.cern.ch/atlas/atlasexternals Most of these externals we build by downloading tar files of their sources from various locations, and building those. Like for instance: https://gitlab.cern.ch/atlas/atlasexternals/blob/master/External/ROOT/CMakeLists.txt (Just to demonstrate how not trivial some of these builds already are...) With one of the latest updates of this repository I started seeing some very unnerving compilation errors in our CI system, which lead me to realise that we've been using ExternalProject_Add(...) in a way so far that's fundamentally not CI compatible. Let's take an example where I have two versions of an external. Let's download these versions in files external-1.0.0.tar.gz, and external-1.0.1.tar.gz. And let's assume that version 1.0.0 was created in January, while 1.0.1 in February of some year. Now, if we just create a very simple ExternalProject_Add(...) configuration, that will just not be incremental build compatible in this setup. Since let's just walk through the build steps. - Let's say that it's March by now. - We first build version 1.0.0 of the external. When ExternalProject_Add(...) unpacks external-1.0.0.tar.gz, the source directory of this project will have modification dates from January. The built files on the other hand will have modification dates from March. (The current date.) - Now we update our build to use version 1.0.1 of the external. When ExternalProject_Add(...) unpacks external-1.0.1.tar.gz, the source files get updated to have modification dates from February. But remember, the build results have a modification date from March. So any reasonable build system that external-1.0.1.tar.gz may use, will not do anything. It will assume that the files in the build directory are already up to date. Of course the issue is even worse when we try to downgrade the version of the external in an update of our own repository. So my question is: Are people not running into this issue all the time? For now I'm thinking of solving this problem like: https://gitlab.cern.ch/akraszna/IncrementalBuildTest/blob/master/CMakeLists.txt Which is a quite drastic approach, but I don't know of a better one. And I wonder if ExternalProject_Add(...) should just behave like this out of the box by default. That whenever it downloads/unpacks a different version of an external than it built before, it should always purge the previous build completely. What does everybody think about this? Am I missing something? Have I been using ExternalProject_Add(...) wrong all along? Cheers, Attila From shreyas.r89 at gmail.com Thu Mar 15 09:29:03 2018 From: shreyas.r89 at gmail.com (Shreyas Ravishankar) Date: Thu, 15 Mar 2018 14:29:03 +0100 Subject: [CMake] managed targeted code requires a '/clr' option cmake fix Message-ID: Hey Guys, Just wanted to find out if there is a way to fix the "*managed targeted code requires a '/clr' option*" error while compiling. The problem is ,this projects has C# dependency. It uses #using(.dll). In VS configuration project settings this can be given but how do you do it using CMake? Please share if you guys know the solution to resolve the issue. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshuabaergen at gmail.com Thu Mar 15 09:52:00 2018 From: joshuabaergen at gmail.com (Joshua Baergen) Date: Thu, 15 Mar 2018 13:52:00 +0000 Subject: [CMake] Link-Time Dependency Injection for Unit Tests In-Reply-To: References: Message-ID: Thanks Eric! That worked perfectly. I had looked at generator expressions yesterday, but didn't understand at which point during makefile generation they were evaluated, and had falsely assumed that they were evaluated too early. Happy to learn new tricks! :) Josh On Thu, Mar 15, 2018 at 2:56 AM Eric Noulard wrote: > Hi Joshua, > > > 2018-03-15 4:18 GMT+01:00 Joshua Baergen : > >> Hello, >> >> I'm attempting to implement link-time dependency injection. In brief, >> what this means is that, for a library A that depends on B, we would >> normally have: >> >> target_link_libraries(A B) >> >> However, when building unittests for A (done in a subdirectory), we >> instead want: >> >> target_link_libraries(A MockB) >> >> I've spent a bunch of time looking through CMake documentation and I'm >> not sure how to express this without resorting to manually specifying the >> link line when A is in use. Could someone give me some guidance? >> > > > Since you want link-time choice I bet you should have a look to some kind > of generator expression > see doc here: > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html > > genex may be used in target_link_libraries. > > for example if you can set some property on (all) your unit test target > (I personnally do that globally by defining my own mytest_add_executable > macro) > > set_target_properties( PROPERTIES UNITTEST 1) > > then may be you can use some genex which check whether an executable if a > unitest: > > set(GenEx_IsTest $,1>) > > and then use some other genex using the previous one in > target_link_libraries > > like here for automatic instantiation of source: > https://cmake.org/pipermail/cmake/2015-January/059669.html > > I lack time to craft the complete example but I think it's doable with > genex. > > It seems that others already played along this line: > https://developer.blender.org/T46725 > > -- > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Mar 15 10:20:07 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 15 Mar 2018 15:20:07 +0100 Subject: [CMake] Link-Time Dependency Injection for Unit Tests In-Reply-To: References: Message-ID: 2018-03-15 14:52 GMT+01:00 Joshua Baergen : > Thanks Eric! That worked perfectly. > > I had looked at generator expressions yesterday, but didn't understand at > which point during makefile generation they were evaluated, and had falsely > assumed that they were evaluated too early. Happy to learn new tricks! :) > You're welcome. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Thu Mar 15 22:17:43 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Thu, 15 Mar 2018 19:17:43 -0700 Subject: [CMake] Advice on how to remove duplicated code for object and interface library setup Message-ID: <89D0B121-F41A-4A4A-8A80-3C39F22B0D5B@cornell.edu> I am trying to obey modern CMake target-based practices, with a twist that everything is available as an OBJECT library if desired. I have this working and can explain why if desired, but I feel it is extraneous for this question. What I create: - mylib <- the main library - mylib_obj <- contains all of the actual objects for the library (OBJECT library) - mylib_interface <- linked with mylib So it looks like this: add_library(mylib_obj OBJECT "") add_library(mylib_interface INTERFACE) Based on various options / settings, target_sources(mylib_obj) will be set and all of the various compiler operations etc. At the end, I have # MYLIB_LIBRARY_TYPE is either SHARED or STATIC add_library(mylib ${MYLIB_LIBRARY_TYPE} $) target_link_libraries(mylib mylib_interface) This works nicely, but internally I have to do the same operations for both mylib_obj and mylib_interface. target_include_directories(mylib_obj PUBLIC ${SomeLib_INCLUDE_DIRS}) target_include_directories(mylib_interface INTERFACE ${SomeLib_INCLUDE_DIRS}) target_link_libraries(mylib_interface INTERFACE ${SomeLib_LIBRARIES}) Without mylib_interface, I cannot include the future linking information as well as include / compiler directive information will not be propagated with target_link_libraries(something mylib). But mylib_obj also needs include information, etc. But I can?t do target_link_libraries(mylib_obj mylib_interface) because mylib_obj is an object library. Is there a way to avoid having to set the same thing for both mylib_obj and mylib_interface given the requirement that mylib_obj is intended to house all of the actual objects? Thank you for any guidance, I?m sorry if this question doesn?t make much sense. I?m trying to unlearn all of my outdated self-taught CMake! -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbahadir at benocs.com Fri Mar 16 10:01:11 2018 From: dbahadir at benocs.com (Deniz Bahadir) Date: Fri, 16 Mar 2018 15:01:11 +0100 Subject: [CMake] Advice on how to remove duplicated code for object and interface library setup In-Reply-To: <89D0B121-F41A-4A4A-8A80-3C39F22B0D5B@cornell.edu> References: <89D0B121-F41A-4A4A-8A80-3C39F22B0D5B@cornell.edu> Message-ID: <03344650-d96e-54bb-e768-e0464f3ee1ea@benocs.com> Am 16.03.2018 um 03:17 schrieb Stephen McDowell: > I am trying to obey modern CMake target-based practices, with a twist > that everything is available as an OBJECT library if desired. ?I have > this working and can explain why if desired, but I feel it is extraneous > for this question. ?What I create: > > - mylib <- the main library > ? ? - mylib_obj <- contains all of the actual objects for the library > (OBJECT library) > ? ? - mylib_interface <- linked with mylib > > So it looks like this: > > ? ? add_library(*mylib_obj OBJECT* "") > **add_library(*mylib_interface INTERFACE*) > > Based on various options / settings, *target_sources(mylib_obj)* will be > set and all of the various compiler operations etc. ?At the end, I have > > ? ? # MYLIB_LIBRARY_TYPE is either SHARED or STATIC > ? ? add_library(*mylib* ${MYLIB_LIBRARY_TYPE} > *$*) > ? ? target_link_libraries(*mylib mylib_interface*) > > This works nicely, but internally?I have to do the same operations for > both *mylib_obj*?and *mylib_interface*. > > ? ? target_include_directories(*mylib_obj PUBLIC* ${SomeLib_INCLUDE_DIRS}) > ? ? target_include_directories(*mylib_interface INTERFACE* > ${SomeLib_INCLUDE_DIRS}) > ? ? target_link_libraries(*mylib_interface INTERFACE* ${SomeLib_LIBRARIES}) > * > * > Without *mylib_interface*, I cannot include the future linking > information as well as include / compiler directive information will not > be propagated with *target_link_libraries(something mylib)*. ?But > *mylib_obj*?also needs include information, etc. *But*?I can?t do > > ? ? target_link_libraries(*mylib_obj mylib_interface*) > * > * > because *mylib_obj*?is an object library. Best idea is to use the latest development-version of CMake from master branch (which will become CMake 3.12). That one supports linking of object-libraries natively like other targets, too. (See: https://gitlab.kitware.com/cmake/cmake/merge_requests/1524) > > Is there a way to avoid having to set the same thing for both > *mylib_obj*?and *mylib_interface*?given the requirement that > *mylib_obj*?is intended to house all of the actual objects? > > Thank you for any guidance, I?m sorry if this question doesn?t make much > sense. ?I?m trying to unlearn all of my outdated self-taught CMake! > > -Stephen > Hope that helps, Deniz From robert.maynard at kitware.com Fri Mar 16 10:14:49 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 16 Mar 2018 10:14:49 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.10.3 available for download Message-ID: We are pleased to announce that CMake 3.10.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.10.3 since 3.10.2: Brad King (1): CMake 3.10.3 Craig Scott (1): GoogleTest: Rename TIMEOUT parameter to avoid clash Sebastian Holtermann (1): Autogen: Fix for the empty source file crash in 3.10.2 Tianhao Chai (1): ccmake: fix status line buffer overflow on very wide terminals From robert.maynard at kitware.com Fri Mar 16 11:31:07 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 16 Mar 2018 11:31:07 -0400 Subject: [CMake] CMAKE In-Reply-To: <163176349.478402.1521065538972@mail.yahoo.com> References: <163176349.478402.1521065538972.ref@mail.yahoo.com> <163176349.478402.1521065538972@mail.yahoo.com> Message-ID: CMake type is based on the OS platform, so you will be good with just having the 64bit version of CMake. Both versions support generating 32 and 64 bit projects. On Wed, Mar 14, 2018 at 6:12 PM, Tettey Nartey via CMake wrote: > I am not entirely sure if I am reaching the right department that receives > questions from mailing list subscribers. My situation really isn't that > complicated, but I myself am troubled by it. I have a 64 bit Operating > system, and I am need to use CMAKE with the CMAKE build files of GLFW. I > would like to know if there is anything wrong with installing both 32 and 64 > bit versions of the CMAKE installer? > > Also, if I am to download the GLFW source package containing the complete > source code, does this mean I won't need to download the pre-compiled source > binaries? Somewhere along the process of setting this all up, I got lost of > track between distinguishing whether I am downloading for a platform I am > making an application for, or for the system I am currently using to make > the application. > > Sincerely, > Tettey Nartey > > > -- > > 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 > From chuck.atkins at kitware.com Fri Mar 16 12:56:06 2018 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 16 Mar 2018 12:56:06 -0400 Subject: [CMake] failure to build Cmake to / against non-standard directory under Linux In-Reply-To: References: Message-ID: CMAKE_PREFIX_PATH just adds a set of search paths. To instead have it shift it's entire search infrastructure, you can use the CMAKE_FIND_ROOT_PATH CMake variable and a few associated with it, which will cause the entire set of search heuristics to be re-rooted in the specified path. First run the bootstrap step: mkdir build cd build ../bootstrap Then use the bootstrapped CMake with the find root path settings: ./Bootstrap.mk/cmake \ -DCMAKE_FIND_ROOT_PATH=/home/tools \ -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY \ -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=ONLY \ -DCMAKE_USE_SYSTEM_LIBRARIES=ON \ -DCMAKE_INSTALL_PREFIX=/home/tools \ .. make -j8 make install - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Fri Mar 16 15:58:31 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 16 Mar 2018 19:58:31 +0000 Subject: [CMake] Install sub project from Visual Studio Message-ID: I know from the command line on a make based system, I can simply make install on an individual project, and it will only install that executable. Is there any way to do the same from visual studio? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From markand at malikania.fr Sat Mar 17 16:29:32 2018 From: markand at malikania.fr (David Demelier) Date: Sat, 17 Mar 2018 21:29:32 +0100 Subject: [CMake] Can't find Boost with Visual Studio 2017 Message-ID: <0ef231f1cee739072b1499713d00ed7a@malikania.fr> Hello all, I've built Booost 1.66 on Windows with Visual Studio 2017 using the following invocation: .\b2 link=shared runtime-link=shared threading=multi toolset=msvc variant=debug address-model=64 install --prefix=C:/env/vs/amd64d Then, the C:/env/vs/amd64d tree is filled like this: - lib/boost_timer-vc141-mt-gd-x64-1_66.lib (and so on) - include/boost-1_66/boost/{asio/assign,...} I create a sample CMake project: cmake_minimum_required(VERSION 3.5) project(foo) find_package(Boost REQUIRED COMPONENTS timer) I set CMAKE_PREFIX_PATH and run CMake set CMAKE_PREFIX_PATH=C:/env/vs/amd64d/ cmake . -G "Visual Studio 15 2017 Win64" [...] -- Detecting CXX compile features - done CMake Warning at C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:567 (message): Imported targets and dependency information not available for Boost version (all versions older than 1.33) Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES) C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1542 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:3 (find_package) CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1928 (message): Unable to find the requested Boost libraries. Unable to find the Boost header files. Please set BOOST_ROOT to the root directory containing Boost or BOOST_INCLUDEDIR to the directory containing Boost's headers. Call Stack (most recent call first): CMakeLists.txt:3 (find_package) -- Configuring incomplete, errors occurred! See also "C:/Users/markand/Documents/test/CMakeFiles/CMakeOutput.log". I can't understand what I am missing because it's not the first time I use boost on Windows though. I've tried set BOOST_ROOT to the same value as CMAKE_PREFIX_PATH with no results. -- David Demelier From saadrustam at gmail.com Sat Mar 17 17:12:51 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Sat, 17 Mar 2018 21:12:51 +0000 Subject: [CMake] Generator Expressions and FetchContent Message-ID: Hi, ExternalProject_Add builds, generates and installs and thus any generator expressions used will be expanded by the time another library uses it. For example, if I add a library LibA using ExternalProject_Add, I can then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the include directory for the library: get_target_property(LibA_INCLUDE_DIRECTORIES LibA INTERFACE_INCLUDE_DIRECTORIES ) This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my CMake include(...) statements. However, with FetchContent, this is no longer possible. The reason I would like to query a variable is because at project generation time, I invoke FetchContent only if LibA is not found by find_package(LibA). Thus, the include directory for LibA may be in the current build directory (through FetchContent) OR it may be found in the folder where LibA is cloned by the user and generated/built OR an INSTALL of LibA. Perhaps I should not be using `get_target_property` to get the a library's include directory? Either way, would like some guidance in solving this issue. Thank you, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Sat Mar 17 18:15:11 2018 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Sat, 17 Mar 2018 23:15:11 +0100 Subject: [CMake] Can't find Boost with Visual Studio 2017 In-Reply-To: <0ef231f1cee739072b1499713d00ed7a@malikania.fr> References: <0ef231f1cee739072b1499713d00ed7a@malikania.fr> Message-ID: <1f072729-e86a-0159-3428-0ce5bf940579@ifm-chemnitz.de> Hi David, Boost changed its naming scheme starting from version 1.66. So its not your fault but the FindBoost.cmake does not know how to handle the new scheme. Try to use one of the 3.11.0-rc[1-3] versions that has the proper naming scheme handling of 1.66 or use the 1.65.1 that is the last version with the old naming scheme. Cheers Volker Am 17.03.2018 um 21:29 schrieb David Demelier: > Hello all, > > I've built Booost 1.66 on Windows with Visual Studio 2017 using the > following invocation: > > ??? .\b2 > ??????? link=shared > ??????? runtime-link=shared > ??????? threading=multi > ??????? toolset=msvc > ??????? variant=debug > ??????? address-model=64 > ??????? install --prefix=C:/env/vs/amd64d > > Then, the C:/env/vs/amd64d tree is filled like this: > > ? - lib/boost_timer-vc141-mt-gd-x64-1_66.lib (and so on) > ? - include/boost-1_66/boost/{asio/assign,...} > > I create a sample CMake project: > > ??? cmake_minimum_required(VERSION 3.5) > ??? project(foo) > ??? find_package(Boost REQUIRED COMPONENTS timer) > > I set CMAKE_PREFIX_PATH and run CMake > > ??? set CMAKE_PREFIX_PATH=C:/env/vs/amd64d/ > ??? cmake . -G "Visual Studio 15 2017 Win64" > > ??? [...] > -- Detecting CXX compile features - done > CMake Warning at C:/Program > Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:567 (message): > ? Imported targets and dependency information not available for Boost > version > ? (all versions older than 1.33) > Call Stack (most recent call first): > ? C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:907 > (_Boost_COMPONENT_DEPENDENCIES) > ? C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1542 > (_Boost_MISSING_DEPENDENCIES) > ? CMakeLists.txt:3 (find_package) > > > CMake Error at C:/Program > Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1928 (message): > ? Unable to find the requested Boost libraries. > > ? Unable to find the Boost header files.? Please set BOOST_ROOT to the > root > ? directory containing Boost or BOOST_INCLUDEDIR to the directory > containing > ? Boost's headers. > Call Stack (most recent call first): > ? CMakeLists.txt:3 (find_package) > > > -- Configuring incomplete, errors occurred! > See also "C:/Users/markand/Documents/test/CMakeFiles/CMakeOutput.log". > > I can't understand what I am missing because it's not the first time I > use boost on Windows though. I've tried set BOOST_ROOT to the same value > as CMAKE_PREFIX_PATH with no results. > From craig.scott at crascit.com Sat Mar 17 18:47:19 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 18 Mar 2018 09:47:19 +1100 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: Can you provide a small project example that can be used to demonstrate your problem? The specifics of how you are doing things may be important. On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak wrote: > Hi, > > ExternalProject_Add builds, generates and installs and thus any generator > expressions used will be expanded by the time another library uses it. > > For example, if I add a library LibA using ExternalProject_Add, I can then > query the target property INTERFACE_INCLUDE_DIRECTORIES and get the include > directory for the library: > > get_target_property(LibA_INCLUDE_DIRECTORIES LibA > INTERFACE_INCLUDE_DIRECTORIES > ) > > This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my > CMake include(...) statements. However, with FetchContent, this is no > longer possible. > > The reason I would like to query a variable is because at project > generation time, I invoke FetchContent only if LibA is not found by > find_package(LibA). > > Thus, the include directory for LibA may be in the current build directory > (through FetchContent) OR it may be found in the folder where LibA is > cloned by the user and generated/built OR an INSTALL of LibA. > > Perhaps I should not be using `get_target_property` to get the a library's > include directory? Either way, would like some guidance in solving this > issue. > > Thank you, > Saad > > > -- > > 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 > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Sun Mar 18 04:34:46 2018 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 18 Mar 2018 08:34:46 +0000 Subject: [CMake] Install sub project from Visual Studio In-Reply-To: References: Message-ID: You can add a custom target which runs cmake -P /cmake_install.cmake Regards, Dvir From: CMake On Behalf Of Scott Bloom Sent: Friday, March 16, 2018 21:59 To: cmake at cmake.org Subject: [Digital Signature Failure] [CMake] Install sub project from Visual Studio I know from the command line on a make based system, I can simply make install on an individual project, and it will only install that executable. Is there any way to do the same from visual studio? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Mar 18 12:44:52 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Sun, 18 Mar 2018 16:44:52 +0000 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: Absolutely. Please find the example project here: https://github.com/samaursa/cmake_fetch_content_and_generator_expressions The repository README also includes the output from running `./setup.sh`. On Sat, Mar 17, 2018 at 6:47 PM Craig Scott wrote: > Can you provide a small project example that can be used to demonstrate > your problem? The specifics of how you are doing things may be important. > > > On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak > wrote: > >> Hi, >> >> ExternalProject_Add builds, generates and installs and thus any generator >> expressions used will be expanded by the time another library uses it. >> >> For example, if I add a library LibA using ExternalProject_Add, I can >> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the >> include directory for the library: >> >> get_target_property(LibA_INCLUDE_DIRECTORIES LibA >> INTERFACE_INCLUDE_DIRECTORIES >> ) >> >> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my >> CMake include(...) statements. However, with FetchContent, this is no >> longer possible. >> >> The reason I would like to query a variable is because at project >> generation time, I invoke FetchContent only if LibA is not found by >> find_package(LibA). >> >> Thus, the include directory for LibA may be in the current build >> directory (through FetchContent) OR it may be found in the folder where >> LibA is cloned by the user and generated/built OR an INSTALL of LibA. >> >> Perhaps I should not be using `get_target_property` to get the a >> library's include directory? Either way, would like some guidance in >> solving this issue. >> >> Thank you, >> Saad >> >> >> -- >> >> 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 >> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Mar 18 16:22:10 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 19 Mar 2018 07:22:10 +1100 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak wrote: > Absolutely. Please find the example project here: https://github.com/ > samaursa/cmake_fetch_content_and_generator_expressions > > The repository README also includes the output from running `./setup.sh`. > Okay that's much clearer, thanks. The example is doing what I'd expect and the generator expressions are also expected to be visible at the point your example is printing them. If you made your main target link against LibA, you'd see that CMake automatically expands out the generator expressions when it constructs the link command line for main, so the example as it stands doesn't actually have any error. Generator expressions are not expanded when CMake is processing the files (called the *configure* stage), they are expanded only when writing out the Makefiles during the *generation* stage. When running cmake from the command line, one doesn't tend to think of these two phases as being distinct, but you can see it at the end of the cmake log with these two messages: -- Configuring done -- Generating done It is clearer when using the CMake GUI application because you get two different buttons, one for Configure and another for Generate, so you have to trigger both phases manually. So if you look at the contents of various properties and variables with CMake commands like message(...), you are doing that during the configure stage and therefore will see unexpanded generator expressions. > > On Sat, Mar 17, 2018 at 6:47 PM Craig Scott > wrote: > >> Can you provide a small project example that can be used to demonstrate >> your problem? The specifics of how you are doing things may be important. >> >> >> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak >> wrote: >> >>> Hi, >>> >>> ExternalProject_Add builds, generates and installs and thus any >>> generator expressions used will be expanded by the time another library >>> uses it. >>> >>> For example, if I add a library LibA using ExternalProject_Add, I can >>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the >>> include directory for the library: >>> >>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA >>> INTERFACE_INCLUDE_DIRECTORIES >>> ) >>> >>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my >>> CMake include(...) statements. However, with FetchContent, this is no >>> longer possible. >>> >>> The reason I would like to query a variable is because at project >>> generation time, I invoke FetchContent only if LibA is not found by >>> find_package(LibA). >>> >>> Thus, the include directory for LibA may be in the current build >>> directory (through FetchContent) OR it may be found in the folder where >>> LibA is cloned by the user and generated/built OR an INSTALL of LibA. >>> >>> Perhaps I should not be using `get_target_property` to get the a >>> library's include directory? Either way, would like some guidance in >>> solving this issue. >>> >>> Thank you, >>> Saad >>> >>> >>> -- >>> >>> 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 >>> >>> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Mar 18 17:25:21 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Sun, 18 Mar 2018 21:25:21 +0000 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: Thank you for the clarification Craig. >> If you made your main target link against LibA, you'd see that CMake automatically expands out the generator expressions when it constructs the link command line for main, so the example as it stands doesn't actually have any error. In my actual project, a library like LibA has .cmake files that can be included by dependent projects to reuse. Of course, CMake `include` does not get affected by target_link_libraries. I would like dependent projects to have the ability to use an existing clone of LibA, if found (e.g. using find_package), otherwise clone locally for using ExternalProject_Add which I am now trying to refactor to FetchContent. Another option open to dependent projects is to force the FetchContent on all repositories regardless of what find_package returns (this is great for testing locally to ensure I have no uncommitted, unpushed changes). Using existing clones is a way to ensure that every project dependent on LibA doesn't clone it's own copy (unless forced to do so). To allow the possibility for any dependent project to include the .cmake files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property (using get_target_property) for LibA and then include the .cmake utility files like this: include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake) Perhaps I am approaching the problem incorrectly? Essentially, I would like a way to reliably include .cmake files found in LibA's include folder regardless of how LibA was acquired (e.g. cloned and built and/or installed separately or acquired using FetchContent). In my case, I could only think of the above as a reliable way to include the files. On Sun, Mar 18, 2018 at 4:22 PM Craig Scott wrote: > On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak > wrote: > >> Absolutely. Please find the example project here: >> https://github.com/samaursa/cmake_fetch_content_and_generator_expressions >> >> >> The repository README also includes the output from running `./setup.sh`. >> > > > Okay that's much clearer, thanks. The example is doing what I'd expect and > the generator expressions are also expected to be visible at the point your > example is printing them. If you made your main target link against LibA, > you'd see that CMake automatically expands out the generator expressions > when it constructs the link command line for main, so the example as it > stands doesn't actually have any error. > > Generator expressions are not expanded when CMake is processing the files > (called the *configure* stage), they are expanded only when writing out > the Makefiles during the *generation* stage. When running cmake from the > command line, one doesn't tend to think of these two phases as being > distinct, but you can see it at the end of the cmake log with these two > messages: > > -- Configuring done > -- Generating done > > It is clearer when using the CMake GUI application because you get two > different buttons, one for Configure and another for Generate, so you have > to trigger both phases manually. So if you look at the contents of various > properties and variables with CMake commands like message(...), you are > doing that during the configure stage and therefore will see unexpanded > generator expressions. > > > > >> >> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott >> wrote: >> >>> Can you provide a small project example that can be used to demonstrate >>> your problem? The specifics of how you are doing things may be important. >>> >>> >>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak >>> wrote: >>> >>>> Hi, >>>> >>>> ExternalProject_Add builds, generates and installs and thus any >>>> generator expressions used will be expanded by the time another library >>>> uses it. >>>> >>>> For example, if I add a library LibA using ExternalProject_Add, I can >>>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the >>>> include directory for the library: >>>> >>>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA >>>> INTERFACE_INCLUDE_DIRECTORIES >>>> ) >>>> >>>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my >>>> CMake include(...) statements. However, with FetchContent, this is no >>>> longer possible. >>>> >>>> The reason I would like to query a variable is because at project >>>> generation time, I invoke FetchContent only if LibA is not found by >>>> find_package(LibA). >>>> >>>> Thus, the include directory for LibA may be in the current build >>>> directory (through FetchContent) OR it may be found in the folder where >>>> LibA is cloned by the user and generated/built OR an INSTALL of LibA. >>>> >>>> Perhaps I should not be using `get_target_property` to get the a >>>> library's include directory? Either way, would like some guidance in >>>> solving this issue. >>>> >>>> Thank you, >>>> Saad >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Sun Mar 18 17:39:58 2018 From: adam.getchell at gmail.com (Adam Getchell) Date: Sun, 18 Mar 2018 14:39:58 -0700 Subject: [CMake] CTest extra tests Message-ID: <09FDFE93-B755-484F-B553-5E43504F0C4D@gmail.com> Hello all, I?m running into unexpected behavior when using CTest. First, I define the list of tests that I want to run in my CMakeLists.txt: https://github.com/acgetchell/CDT-plusplus/blob/develop/CMakeLists.txt#L151 However, it generates two extra tests: ??[adam][hapkido][?][develop {1} ?][~/CDT-plusplus/build] ??? ctest -N Test project /Users/adam/CDT-plusplus/build Test #1: cdt-gv Test #2: build_target_cdt-gv Test #3: CDT-Usage Test #4: CDT-3Donly Test #5: CDT-Simplices Test #6: CDT-Timeslices Test #7: CDT-3Dtriangle Test #8: CDT-MinimalS3 Test #9: CDT-S3Runs Test #10: CDT-unit-tests Total Tests: 10 I?d like to get rid of these first two autogenerated tests, because #1 fails. Where/how are these being generated/defined? I?m aware that I can just filter using ctest -E, but I?d like to make it easy for the other contributors (and my CI) by making `ctest` just work. Thanks for any pointers. Cheers, Adam -- Adam Getchell https://keybase.io/adamgetchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickfrank at me.com Sun Mar 18 18:18:34 2018 From: rickfrank at me.com (Richard Frank) Date: Sun, 18 Mar 2018 18:18:34 -0400 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) Message-ID: Hi I?m trying out Visual Studio Code on Ubuntu 16.04. There?s support for CMake built in but if I use CMake externally was generator should I use? Thanks Rick Frank From andrew.gaspar at outlook.com Sun Mar 18 22:07:33 2018 From: andrew.gaspar at outlook.com (Andrew Gaspar) Date: Mon, 19 Mar 2018 02:07:33 +0000 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) In-Reply-To: References: Message-ID: Hm, I?m not sure what you mean by built in support, but there is an excellent plugin you should install: https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools It gives you easy interface extensions for building, debugging, or testing your project. You shouldn?t need to use a specific Generator ? by default CMake Tools will use the default generator (I think). So Makefiles should be fine. Is that what you were looking for? Andrew Gaspar ________________________________ From: CMake on behalf of Richard Frank Sent: Sunday, March 18, 2018 4:18:34 PM To: cmake at cmake.org Subject: [CMake] Generator for Visual Studio Code (Ubuntu) Hi I?m trying out Visual Studio Code on Ubuntu 16.04. There?s support for CMake built in but if I use CMake externally was generator should I use? Thanks Rick Frank -- Powered by https://eur03.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=WxauxUOq51ZRIp656qtFNI5U16CBz3kFhCIYUwUoP94%3D&reserved=0 Please keep messages on-topic and check the CMake FAQ at: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=lwzT5B3kjsfTjMmeEIlrCtGFfekNSOVPcxmjvhKs64s%3D&reserved=0 Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=eSXn18Hr1jYlsgSr7tZd6dvoLKb6x9o2ZdwD%2FGe2o%2B8%3D&reserved=0 CMake Consulting: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=4q%2By3fqm11Du4ZfavRlSXjuX2VkBeYpfjx57cq2Xq6A%3D&reserved=0 CMake Training Courses: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=FRKO1XfW8Ig63ewieK7fyLjSd%2B82m8a2GQc9li5KSU4%3D&reserved=0 Visit other Kitware open-source projects at https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=c7EIM23%2FTAWSfOizVV7nJq2xo9fr1Yt12%2FZE3jxs780%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=UhiwQSBUPtslzKxdRzig0iRkU6uaTGd8Uq55o2Nbn%2BY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickfrank at me.com Mon Mar 19 06:51:45 2018 From: rickfrank at me.com (Richard Frank) Date: Mon, 19 Mar 2018 06:51:45 -0400 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) In-Reply-To: References: Message-ID: <45AC68DE-60B0-4467-8F3A-AA6FD5EA6793@me.com> Yes I have that plugin. But for more complex build systems that build multiple products, running CMake from a shell script, I wondered what generator would be used, Sent from my iPad > On Mar 18, 2018, at 10:07 PM, Andrew Gaspar wrote: > > Hm, I?m not sure what you mean by built in support, but there is an excellent plugin you should install: https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools > > It gives you easy interface extensions for building, debugging, or testing your project. You shouldn?t need to use a specific Generator ? by default CMake Tools will use the default generator (I think). So Makefiles should be fine. > > Is that what you were looking for? > > Andrew Gaspar > > From: CMake on behalf of Richard Frank > Sent: Sunday, March 18, 2018 4:18:34 PM > To: cmake at cmake.org > Subject: [CMake] Generator for Visual Studio Code (Ubuntu) > > Hi > > I?m trying out Visual Studio Code on Ubuntu 16.04. There?s support for CMake built in but if I use CMake externally was generator should I use? > > Thanks > > Rick Frank > -- > > Powered by https://eur03.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=WxauxUOq51ZRIp656qtFNI5U16CBz3kFhCIYUwUoP94%3D&reserved=0 > > Please keep messages on-topic and check the CMake FAQ at: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=lwzT5B3kjsfTjMmeEIlrCtGFfekNSOVPcxmjvhKs64s%3D&reserved=0 > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=eSXn18Hr1jYlsgSr7tZd6dvoLKb6x9o2ZdwD%2FGe2o%2B8%3D&reserved=0 > CMake Consulting: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=4q%2By3fqm11Du4ZfavRlSXjuX2VkBeYpfjx57cq2Xq6A%3D&reserved=0 > CMake Training Courses: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=FRKO1XfW8Ig63ewieK7fyLjSd%2B82m8a2GQc9li5KSU4%3D&reserved=0 > > Visit other Kitware open-source projects at https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=c7EIM23%2FTAWSfOizVV7nJq2xo9fr1Yt12%2FZE3jxs780%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636570119238976995&sdata=UhiwQSBUPtslzKxdRzig0iRkU6uaTGd8Uq55o2Nbn%2BY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Mon Mar 19 06:54:50 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 19 Mar 2018 11:54:50 +0100 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) In-Reply-To: <45AC68DE-60B0-4467-8F3A-AA6FD5EA6793@me.com> References: <45AC68DE-60B0-4467-8F3A-AA6FD5EA6793@me.com> Message-ID: On 19 March 2018 at 11:51, Richard Frank wrote: > Yes I have that plugin. But for more complex build systems that build > multiple products, running CMake from a shell script, I wondered what > generator would be used, FWIW, there no such thing as CMake generator for "Visual Studio Code". VSCode is generator-agnostic. For current list of generators, refer to the CMake docs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mateusz at loskot.net Mon Mar 19 07:06:09 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 19 Mar 2018 12:06:09 +0100 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) In-Reply-To: <47813A0C-24AA-4EBE-9543-497E6C2167C5@me.com> References: <45AC68DE-60B0-4467-8F3A-AA6FD5EA6793@me.com> <47813A0C-24AA-4EBE-9543-497E6C2167C5@me.com> Message-ID: (you missed to reply to the mailing list!) On 19 March 2018 at 11:58, Richard Frank wrote: > Ok fair enough. So. I can output Unix make files and VS code can load those? Yes. If you have read the vscode-cmake extension docs https://vector-of-bool.github.io/, you would have seen that there is no generator required, you can choose. Consider another example: if you use Visual Studio 2017 with its CMake integration [1], you don't have to limit yourself to VisualStudio/MSBuild generator just becasue you use CMake inside Visual Studio. You can use Ninja too. [1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From craig.scott at crascit.com Mon Mar 19 07:11:01 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 19 Mar 2018 22:11:01 +1100 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak wrote: > Thank you for the clarification Craig. > > >> If you made your main target link against LibA, you'd see that CMake > automatically expands out the generator expressions when it constructs the > link command line for main, so the example as it stands doesn't actually > have any error. > > In my actual project, a library like LibA has .cmake files that can be > included by dependent projects to reuse. Of course, CMake `include` does > not get affected by target_link_libraries. > > I would like dependent projects to have the ability to use an existing > clone of LibA, if found (e.g. using find_package), otherwise clone locally > for using ExternalProject_Add which I am now trying to refactor to > FetchContent. Another option open to dependent projects is to force the > FetchContent on all repositories regardless of what find_package returns > (this is great for testing locally to ensure I have no uncommitted, > unpushed changes). > > Using existing clones is a way to ensure that every project dependent on > LibA doesn't clone it's own copy (unless forced to do so). > > To allow the possibility for any dependent project to include the .cmake > files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property > (using get_target_property) for LibA and then include the .cmake utility > files like this: > > include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake) > > Perhaps I am approaching the problem incorrectly? Essentially, I would > like a way to reliably include .cmake files found in LibA's include folder > regardless of how LibA was acquired (e.g. cloned and built and/or installed > separately or acquired using FetchContent). In my case, I could only think > of the above as a reliable way to include the files. > Rather than focusing on including files, I would choose to base things around targets. If the rest of your project simply links against the required target name, the target itself should bring with it any transitive dependencies such as required header search paths, dependent libraries that must also be linked, etc. These are the INTERFACE_... properties that can be set on a target, usually by commands such as target_include_directories(foo INTERFACE ...), target_link_libraries(foo INTERFACE ...), etc. When building directly from your source tree, the targets will be directly available. When using find_package(), the package should provide import targets. The rest of your project shouldn't really need to care which one of the two it is dealing with. This is the recommended way to structure a situation like this. You shouldn't need to also pull in a secondary .cmake file in most circumstances, but maybe I'm missing something about your particular situation. > > On Sun, Mar 18, 2018 at 4:22 PM Craig Scott > wrote: > >> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak >> wrote: >> >>> Absolutely. Please find the example project here: https://github.com/ >>> samaursa/cmake_fetch_content_and_generator_expressions >>> >>> The repository README also includes the output from running >>> `./setup.sh`. >>> >> >> >> Okay that's much clearer, thanks. The example is doing what I'd expect >> and the generator expressions are also expected to be visible at the point >> your example is printing them. If you made your main target link against >> LibA, you'd see that CMake automatically expands out the generator >> expressions when it constructs the link command line for main, so the >> example as it stands doesn't actually have any error. >> >> Generator expressions are not expanded when CMake is processing the files >> (called the *configure* stage), they are expanded only when writing out >> the Makefiles during the *generation* stage. When running cmake from the >> command line, one doesn't tend to think of these two phases as being >> distinct, but you can see it at the end of the cmake log with these two >> messages: >> >> -- Configuring done >> -- Generating done >> >> It is clearer when using the CMake GUI application because you get two >> different buttons, one for Configure and another for Generate, so you have >> to trigger both phases manually. So if you look at the contents of various >> properties and variables with CMake commands like message(...), you are >> doing that during the configure stage and therefore will see unexpanded >> generator expressions. >> >> >> >> >>> >>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott >>> wrote: >>> >>>> Can you provide a small project example that can be used to demonstrate >>>> your problem? The specifics of how you are doing things may be important. >>>> >>>> >>>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> ExternalProject_Add builds, generates and installs and thus any >>>>> generator expressions used will be expanded by the time another library >>>>> uses it. >>>>> >>>>> For example, if I add a library LibA using ExternalProject_Add, I can >>>>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the >>>>> include directory for the library: >>>>> >>>>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA >>>>> INTERFACE_INCLUDE_DIRECTORIES >>>>> ) >>>>> >>>>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my >>>>> CMake include(...) statements. However, with FetchContent, this is no >>>>> longer possible. >>>>> >>>>> The reason I would like to query a variable is because at project >>>>> generation time, I invoke FetchContent only if LibA is not found by >>>>> find_package(LibA). >>>>> >>>>> Thus, the include directory for LibA may be in the current build >>>>> directory (through FetchContent) OR it may be found in the folder where >>>>> LibA is cloned by the user and generated/built OR an INSTALL of LibA. >>>>> >>>>> Perhaps I should not be using `get_target_property` to get the a >>>>> library's include directory? Either way, would like some guidance in >>>>> solving this issue. >>>>> >>>>> Thank you, >>>>> Saad >>>>> >>>> >> -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Mon Mar 19 07:27:24 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Mon, 19 Mar 2018 04:27:24 -0700 Subject: [CMake] Generator for Visual Studio Code (Ubuntu) In-Reply-To: References: <45AC68DE-60B0-4467-8F3A-AA6FD5EA6793@me.com> <47813A0C-24AA-4EBE-9543-497E6C2167C5@me.com> Message-ID: <0B2A9292-D4E2-4950-8AFC-9F0FC97A20E3@cornell.edu> You may also find this article useful, it seems to explain how to configure the JSON files you need to for more complicated build systems: https://medium.com/audelabs/c-development-using-visual-studio-code-cmake-and-lldb-d0f13d38c563 They were writing for Linux / OS X, and you?ll see that they?re just using cmake -G 'Unix Makefiles? in their tasks.json. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Mar 19 07:39:47 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 19 Mar 2018 12:39:47 +0100 Subject: [CMake] Make ctest spit out xml file (without dashboard) Message-ID: Hi there, Is it possible to make ctest spit out its result in an xml formatted file without sending it to some dashboard. ? I only need something xml-parsable ctest output locally. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 19 07:54:08 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 19 Mar 2018 07:54:08 -0400 Subject: [CMake] Cmake Frameworks and Bitcode In-Reply-To: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: On 03/12/2018 10:36 AM, Cameron Palmer wrote: > So after a bit of hacking it seems that Cmake should provide something like: > > CMAKE_OSX_BITCODE_ENABLE For reference, this refers to a previous post: Bitcode and CMake https://cmake.org/pipermail/cmake/2018-March/067191.html with the goal of using `-fembed-bitcode` while avoiding a warning: ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) > Which would pass -fembed-bitcode to the compiler and linker and remove > the option in Darwin.cmake for -Wl,-headerpad_max_install_names in > CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS. One may avoid the `-headerpad_max_install_names` option with this: https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html There is no reason to build with any rpath set for the build tree when one cannot run the binaries on the macOS host anyway. -Brad From craig.scott at crascit.com Mon Mar 19 08:14:46 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 19 Mar 2018 23:14:46 +1100 Subject: [CMake] Make ctest spit out xml file (without dashboard) In-Reply-To: References: Message-ID: On Mon, Mar 19, 2018 at 10:39 PM, Eric Noulard wrote: > Hi there, > > Is it possible to make ctest spit out its result in an xml formatted file > without > sending it to some dashboard. ? > Yes, you can control the individual steps of a full dashboard run and just leave out the submit step. For example: ctest -T Start -T Update -T Configure -T Build -T Test -T Coverage -T MemCheck Leave out any of the above -T actions you don't need. XML result files will be in a Testing/YYYYMMDD-hhmm directory and log files in Testing/Temporary. The Start action creates a new YYYYMMDD-hhmm timestamp directory that the rest of the steps will then store their XML result files in. The first line of the file at Testing/TAG records that timestamp and the second line in there you won't care about if not submitting the results to a dashboard. Hopefully that gets you far enough along to what you need. > > I only need something xml-parsable ctest output locally. > > -- > Eric > > -- > > 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 > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Mon Mar 19 08:51:18 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 19 Mar 2018 12:51:18 +0000 Subject: [CMake] Generator Expressions and FetchContent In-Reply-To: References: Message-ID: I do use target_link_libraries when it comes to C++ projects and it works wonderfully for them. However, in this case, my base project has a bunch of helper files with CMake functionality that help me work with and build my library of projects (which you can see here https://github.com/2LoC/tl_base_ci). Of course, these helper .cmake files (with the functionality I want) are in the tl_base_ci project which can be either (1) cloned separately, built, (2) Installed without building, or (3) cloned through ExternalProject_Add (which I am trying to convert to FetchContent). In all cases, the include directories might differ, which is why I use rely on the generator expressions expanding. In projects depending on tl_base_ci (e.g. https://github.com/2LoC/tl_proj_template), I have CMake includes like this: include("${tl_base_ci_INCLUDE_DIRECTORY}/tl_base_ci/tl_common.cmake") # in the actual project, it's slightly different as it searches for the file in a list of directories returned by get_target_property(... INTERFACE_INCLUDE_DIRECTORIES) Where the tl_base_ci_INCLUDE_DIRECTORY might differ. So ultimately I was hoping for a way to reliably include the helper .cmake files (i.e. figure out tl_base_ci's include directory path). I did that with get_target_property(...) which worked great for ExternalProject_Add, but did not work so well for FetchContent because the generator expressions did not expand. Hopefully I was able to explain the problem well. If there is any confusion, please let me know. On Mon, Mar 19, 2018 at 7:11 AM Craig Scott wrote: > On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak > wrote: > >> Thank you for the clarification Craig. >> >> >> If you made your main target link against LibA, you'd see that CMake >> automatically expands out the generator expressions when it constructs the >> link command line for main, so the example as it stands doesn't actually >> have any error. >> >> In my actual project, a library like LibA has .cmake files that can be >> included by dependent projects to reuse. Of course, CMake `include` does >> not get affected by target_link_libraries. >> >> I would like dependent projects to have the ability to use an existing >> clone of LibA, if found (e.g. using find_package), otherwise clone locally >> for using ExternalProject_Add which I am now trying to refactor to >> FetchContent. Another option open to dependent projects is to force the >> FetchContent on all repositories regardless of what find_package returns >> (this is great for testing locally to ensure I have no uncommitted, >> unpushed changes). >> >> Using existing clones is a way to ensure that every project dependent on >> LibA doesn't clone it's own copy (unless forced to do so). >> >> To allow the possibility for any dependent project to include the .cmake >> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property >> (using get_target_property) for LibA and then include the .cmake utility >> files like this: >> >> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake) >> >> Perhaps I am approaching the problem incorrectly? Essentially, I would >> like a way to reliably include .cmake files found in LibA's include folder >> regardless of how LibA was acquired (e.g. cloned and built and/or installed >> separately or acquired using FetchContent). In my case, I could only think >> of the above as a reliable way to include the files. >> > > Rather than focusing on including files, I would choose to base things > around targets. If the rest of your project simply links against the > required target name, the target itself should bring with it any transitive > dependencies such as required header search paths, dependent libraries that > must also be linked, etc. These are the INTERFACE_... properties that can > be set on a target, usually by commands such as > target_include_directories(foo INTERFACE ...), target_link_libraries(foo > INTERFACE ...), etc. When building directly from your source tree, the > targets will be directly available. When using find_package(), the package > should provide import targets. The rest of your project shouldn't really > need to care which one of the two it is dealing with. This is the > recommended way to structure a situation like this. You shouldn't need to > also pull in a secondary .cmake file in most circumstances, but maybe I'm > missing something about your particular situation. > > > >> >> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott >> wrote: >> >>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak >>> wrote: >>> >>>> Absolutely. Please find the example project here: >>>> https://github.com/samaursa/cmake_fetch_content_and_generator_expressions >>>> >>>> >>>> The repository README also includes the output from running >>>> `./setup.sh`. >>>> >>> >>> >>> Okay that's much clearer, thanks. The example is doing what I'd expect >>> and the generator expressions are also expected to be visible at the point >>> your example is printing them. If you made your main target link >>> against LibA, you'd see that CMake automatically expands out the >>> generator expressions when it constructs the link command line for main, >>> so the example as it stands doesn't actually have any error. >>> >>> Generator expressions are not expanded when CMake is processing the >>> files (called the *configure* stage), they are expanded only when >>> writing out the Makefiles during the *generation* stage. When running >>> cmake from the command line, one doesn't tend to think of these two phases >>> as being distinct, but you can see it at the end of the cmake log with >>> these two messages: >>> >>> -- Configuring done >>> -- Generating done >>> >>> It is clearer when using the CMake GUI application because you get two >>> different buttons, one for Configure and another for Generate, so you have >>> to trigger both phases manually. So if you look at the contents of various >>> properties and variables with CMake commands like message(...), you are >>> doing that during the configure stage and therefore will see unexpanded >>> generator expressions. >>> >>> >>> >>> >>>> >>>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott >>>> wrote: >>>> >>>>> Can you provide a small project example that can be used to >>>>> demonstrate your problem? The specifics of how you are doing things may be >>>>> important. >>>>> >>>>> >>>>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> ExternalProject_Add builds, generates and installs and thus any >>>>>> generator expressions used will be expanded by the time another library >>>>>> uses it. >>>>>> >>>>>> For example, if I add a library LibA using ExternalProject_Add, I can >>>>>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the >>>>>> include directory for the library: >>>>>> >>>>>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA >>>>>> INTERFACE_INCLUDE_DIRECTORIES >>>>>> ) >>>>>> >>>>>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in >>>>>> my CMake include(...) statements. However, with FetchContent, this is no >>>>>> longer possible. >>>>>> >>>>>> The reason I would like to query a variable is because at project >>>>>> generation time, I invoke FetchContent only if LibA is not found by >>>>>> find_package(LibA). >>>>>> >>>>>> Thus, the include directory for LibA may be in the current build >>>>>> directory (through FetchContent) OR it may be found in the folder where >>>>>> LibA is cloned by the user and generated/built OR an INSTALL of LibA. >>>>>> >>>>>> Perhaps I should not be using `get_target_property` to get the a >>>>>> library's include directory? Either way, would like some guidance in >>>>>> solving this issue. >>>>>> >>>>>> Thank you, >>>>>> Saad >>>>>> >>>>> >>> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Mar 19 09:37:09 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 19 Mar 2018 14:37:09 +0100 Subject: [CMake] Make ctest spit out xml file (without dashboard) In-Reply-To: References: Message-ID: 2018-03-19 13:14 GMT+01:00 Craig Scott : > > > On Mon, Mar 19, 2018 at 10:39 PM, Eric Noulard > wrote: > >> Hi there, >> >> Is it possible to make ctest spit out its result in an xml formatted file >> without >> sending it to some dashboard. ? >> > > Yes, you can control the individual steps of a full dashboard run and just > leave out the submit step. For example: > > ctest -T Start -T Update -T Configure -T Build -T Test -T Coverage -T > MemCheck > > Leave out any of the above -T actions you don't need. XML result files > will be in a Testing/YYYYMMDD-hhmm directory and log files in > Testing/Temporary. The Start action creates a new YYYYMMDD-hhmm timestamp > directory that the rest of the steps will then store their XML result files > in. The first line of the file at Testing/TAG records that timestamp and > the second line in there you won't care about if not submitting the results > to a dashboard. > > Hopefully that gets you far enough along to what you need. > This is indeed far just enough for my needs. Thank you very much Craig. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From markand at malikania.fr Mon Mar 19 10:17:08 2018 From: markand at malikania.fr (David Demelier) Date: Mon, 19 Mar 2018 15:17:08 +0100 Subject: [CMake] Can't find Boost with Visual Studio 2017 In-Reply-To: <1f072729-e86a-0159-3428-0ce5bf940579@ifm-chemnitz.de> References: <0ef231f1cee739072b1499713d00ed7a@malikania.fr> <1f072729-e86a-0159-3428-0ce5bf940579@ifm-chemnitz.de> Message-ID: <1521469028.10685.0.camel@malikania.fr> On Sat, 2018-03-17 at 23:15 +0100, Volker Enderlein wrote: > Hi David, > > Boost changed its naming scheme starting from version 1.66. So its > not > your fault but the FindBoost.cmake does not know how to handle the > new > scheme. Try to use one of the 3.11.0-rc[1-3] versions that has the > proper naming scheme handling of 1.66 or use the 1.65.1 that is the > last > version with the old naming scheme. > Hello, Indeed, it works with CMake 3.11, thanks a lot :) -- David From robert.maynard at kitware.com Mon Mar 19 11:13:54 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 19 Mar 2018 11:13:54 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc4 is now ready for testing Message-ID: I am proud to announce the fourth CMake 3.11 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc3: Brad King (6): Genex: Fix COMPILE_LANGUAGE in SYSTEM include directories Genex: Fix COMPILE_LANGUAGE propagation through try_compile XL: Fix C default level detection when invoked as 'cc' Features: Record initializer list support for Intel 14 and above FindQt4: Revert "Set PLUGINS and IMPORTS dir even if empty" CMake 3.11.0-rc4 Craig Scott (1): GoogleTest: Rename TIMEOUT parameter to avoid clash Jean-Christophe Fillion-Robin (1): ExternalProject: Fix cache generation when last args ends with "-NOTFOUND" Kai Wolf (1): Help: Adapt cmake-buildsystem(7) to new IMPORTED targets features Tianhao Chai (1): ccmake: fix status line buffer overflow on very wide terminals YunQiang Su (1): FindJNI: add some new architecture names for mips release 6 From miroslav.kes at gmail.com Tue Mar 20 11:21:49 2018 From: miroslav.kes at gmail.com (=?UTF-8?Q?Miroslav_Ke=c5=a1?=) Date: Tue, 20 Mar 2018 16:21:49 +0100 Subject: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling Message-ID: Hi! I have question concerning the file(TO_NATIVE_PATH ...) behavior. The documentation says: "The TO_NATIVE_PATH mode converts a cmake-style into a native path with platform-specific slashes (\ on Windows and / elsewhere)." ... but it doesn't say if the decision is made based on the CMAKE_SYSTEM_NAME or the CMAKE_HOST_SYSTEM_NAME. I have a project that builds the code for multiple platforms. The conversion works OK when building for Linux on Linux host or when building for Windows on a Windows host. But if I cross-compile on a Windows for a non-Windows platform, the file(TO_NATIVE_PATH ...) converts paths to the target "non Windows" platform convention. Is this the expected behavior? I was going to use it when calling external programs on the build host (e.g. to generate Doxygen config file from a template using configure_file() ). But it doesn't work because of the target host path convention output. Thanks. Mira From bill.hoffman at kitware.com Tue Mar 20 12:45:58 2018 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 20 Mar 2018 12:45:58 -0400 Subject: [CMake] CTest extra tests In-Reply-To: <09FDFE93-B755-484F-B553-5E43504F0C4D@gmail.com> References: <09FDFE93-B755-484F-B553-5E43504F0C4D@gmail.com> Message-ID: Must be coming from some macro, cmake does not automatically add any tests. You could run cmake --trace and look at the output and find out where the add_test call is coming from. On Sun, Mar 18, 2018 at 5:39 PM, Adam Getchell wrote: > Hello all, > > I?m running into unexpected behavior when using CTest. > > First, I define the list of tests that I want to run in my CMakeLists.txt: > > https://github.com/acgetchell/CDT-plusplus/blob/develop/ > CMakeLists.txt#L151 > > However, it generates two extra tests: > > ??[*adam*][hapkido][*?*][develop {1} *?*][~/CDT-plusplus/build] > ??? ctest -N > Test project /Users/adam/CDT-plusplus/build > Test #1: cdt-gv > Test #2: build_target_cdt-gv > Test #3: CDT-Usage > Test #4: CDT-3Donly > Test #5: CDT-Simplices > Test #6: CDT-Timeslices > Test #7: CDT-3Dtriangle > Test #8: CDT-MinimalS3 > Test #9: CDT-S3Runs > Test #10: CDT-unit-tests > > Total Tests: 10 > > I?d like to get rid of these first two autogenerated tests, because #1 > fails. Where/how are these being generated/defined? > > I?m aware that I can just filter using ctest -E, but I?d like to make it > easy for the other contributors (and my CI) by making `ctest` just work. > > Thanks for any pointers. > > Cheers, > Adam > -- > Adam Getchell > https://keybase.io/adamgetchell > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Tue Mar 20 16:14:30 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 20 Mar 2018 21:14:30 +0100 Subject: [CMake] [proposal] Support for modern CMake Message-ID: Hi, I've used CMake for a 10+ years now. I'm not a newbie, but I still discover CMake awesomeness as well as its traps. Now, I'm trying to catch up with the modern CMake party and I obviously watched the famous Daniel Pfeifer's lecture [1] (I'm late, I know!) I asked a simple question on #cmake at cpplang.slack.com: Given add_executable(app app.cpp) target_link_libraries(app PRIVATE Boost::filesystem) Is that correct to expect the myapp target is also configured with all the corresponding ***include*** directories (ie. Boost headers location)? Or, do I need to call anything else, like: target_include_directories(app PRIVATE Boost::boost) Then, I realised that the current CMake API is does not follow its own evolution that happened recently leaving lots of room for semantical ambiguity. In the 'old school' CMake, I would write: target_link_libraries(app ${Boost_LIBRARIES}) target_include_directories(app ${Boost_INCLUDE_DIRS}) All is clear and explicit. In the modern CMake, I write: target_link_libraries(app Boost::system) Is all equally clear here? No! Why CMake does not follow its own evolution and does not update its API with **new** commands to support the modern CMake? Why I can not write: target_use(app Boost::system Boost::filesystem) or target_use_targets(app Boost::system Boost::filesystem) and, actually read and understand what I'm doing? (If you're now typing "why don't you create a custom macro wrapper" response, please don't!) How nicely it would fit into the concept of CMake member functions presented by Daniel [1] (@17:25 min), wouldn't it? Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] use_targets(app Boost::system) and I just renamed it to fit in the Daniel's concept of looking at CMake API as OOP, that is OOP like in C in GTK+ :), of course. [1] https://twitter.com/mloskot/status/973914895287713793 [2] https://github.com/vector-of-bool/vscode-cmake-tools [3] https://cpplang.slack.com/archives/C5Y2GDECX/p1521227050000490 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From neundorf at kde.org Tue Mar 20 16:52:42 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 20 Mar 2018 21:52:42 +0100 Subject: [CMake] [proposal] Support for modern CMake In-Reply-To: References: Message-ID: <84534259.EJmlnaiSMg@linux-l7nd> On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: ... > Why I can not write: > > target_use(app Boost::system Boost::filesystem) > > or > > target_use_targets(app Boost::system Boost::filesystem) > > and, actually read and understand what I'm doing? > > (If you're now typing "why don't you create a custom macro wrapper" > response, please don't!) > > How nicely it would fit into the concept of CMake member functions > presented by Daniel [1] (@17:25 min), wouldn't it? > > > Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] > use_targets(app Boost::system) Not sure, I guess I was earlier ;-) You may want to have a look at https://cmake.org/pipermail/cmake-developers/2012-December/017561.html and the following discussion. Alex From mateusz at loskot.net Tue Mar 20 17:26:58 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 20 Mar 2018 22:26:58 +0100 Subject: [CMake] [proposal] Support for modern CMake In-Reply-To: <84534259.EJmlnaiSMg@linux-l7nd> References: <84534259.EJmlnaiSMg@linux-l7nd> Message-ID: On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) Alex, please accept my apologies. I should have used s/Originally/I've learned about/ :) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. I'm eager to have a look, thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From adam.getchell at gmail.com Tue Mar 20 18:27:45 2018 From: adam.getchell at gmail.com (Adam Getchell) Date: Tue, 20 Mar 2018 15:27:45 -0700 Subject: [CMake] CTest extra tests In-Reply-To: References: <09FDFE93-B755-484F-B553-5E43504F0C4D@gmail.com> Message-ID: <9C0B4B08-93C7-4300-8BA5-450CA451BE7D@gmail.com> > On Mar 20, 2018, at 9:45 AM, Bill Hoffman wrote: > > Must be coming from some macro, cmake does not automatically add any tests. You could run cmake --trace and look at the output and find out where the add_test call is coming from. Thanks, that was it! The create_single_source_cgal_program() macro was the culprit. Thanks for the pointer to cmake --trace > > On Sun, Mar 18, 2018 at 5:39 PM, Adam Getchell > wrote: > Hello all, > > I?m running into unexpected behavior when using CTest. > > First, I define the list of tests that I want to run in my CMakeLists.txt: > > https://github.com/acgetchell/CDT-plusplus/blob/develop/CMakeLists.txt#L151 > > However, it generates two extra tests: > > ??[adam][hapkido][?][develop {1} ?][~/CDT-plusplus/build] > ??? ctest -N > Test project /Users/adam/CDT-plusplus/build > Test #1: cdt-gv > Test #2: build_target_cdt-gv > Test #3: CDT-Usage > Test #4: CDT-3Donly > Test #5: CDT-Simplices > Test #6: CDT-Timeslices > Test #7: CDT-3Dtriangle > Test #8: CDT-MinimalS3 > Test #9: CDT-S3Runs > Test #10: CDT-unit-tests > > Total Tests: 10 > > I?d like to get rid of these first two autogenerated tests, because #1 fails. Where/how are these being generated/defined? > > I?m aware that I can just filter using ctest -E, but I?d like to make it easy for the other contributors (and my CI) by making `ctest` just work. > > Thanks for any pointers. > > Cheers, > Adam > -- > Adam Getchell > https://keybase.io/adamgetchell > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmann at latencyzero.com Tue Mar 20 20:52:10 2018 From: rmann at latencyzero.com (Rick Mann) Date: Tue, 20 Mar 2018 17:52:10 -0700 Subject: [CMake] target_compile_features no known features for CXX compiler for clang 9.0 Message-ID: Trying to build Ceres, I'm running into an issue in which CMake 3.11.0-rc3 doesn't seem to recognize the clang that comes with the latest Xcode (Version 9.2 (9C40b)). Googling turns up similar, but old results, that seem to suggest one needs to update CMake. But -rc4 is the only more recent version, and its release notes don't say anything about this. CMake Error at cmake/AddCeresCXX11RequirementsToTarget.cmake:70 (target_compile_features): target_compile_features no known features for CXX compiler "Clang" version 9.0.0.9000039. Any suggestions? Thanks. -- Rick Mann From mario at emmenlauer.de Wed Mar 21 05:55:38 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Wed, 21 Mar 2018 10:55:38 +0100 Subject: [CMake] find_package() for static only / shared only Message-ID: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> I've googled this issue for a while now but found only few references (1,2) and no solution. I'd like to enforce that find_package() will only accept static or shared libraries. I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). I.e. I'd love to have something like: if(BUILD_SHARED_LIBS) BUILD_TYPE="SHARED" else() BUILD_TYPE="STATIC" endif() find_package(XXX ${BUILD_TYPE}) find_package(YYY ${BUILD_TYPE}) find_package(ZZZ ${BUILD_TYPE}) ... It seems that this does not exist? I could also not find a good workaround. The best I can find is to use 'NAMES' and add the static or shared library names manually. This is not very suitable, because I have a project with more than 30 dependencies. The project should either build (fully) static or (fully) shared. I can not easily maintain lists of 30 static and shared library names on several platforms. Is there a solution or good workaround? All the best, Mario Emmenlauer (1) https://cmake.org/pipermail/cmake/2012-September/052059.html (2) https://cmake.org/pipermail/cmake/2010-December/041326.html -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From mario at emmenlauer.de Wed Mar 21 05:31:48 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Wed, 21 Mar 2018 10:31:48 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? Message-ID: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> Dear All, I use find_package(ZLIB) to detect zlib on Ubuntu 16.04 Linux. I have a newer zlib in /data/thirdparty that I'd like to use. To prefer my newer version I add -DCMAKE_PREFIX_PATH="/data/thirdparty". In my understanding, the documentation says CMAKE_PREFIX_PATH is searched first (1). But cmake behaves different than I'd expect: It detects the system zlib first: -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8") And then complains that zlib exists twice: CMake Warning at CMakeLists.txt:693 (add_library): Cannot generate a safe runtime search path for target bdaimage because files in some directories may conflict with libraries in implicit directories: runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in: /data/thirdparty/lib Some of these libraries may not be found correctly. Why am I misunderstanding the documentation? Is CMAKE_PREFIX_PATH not preferred over system directories? All the best, Mario Emmenlauer (1) https://cmake.org/cmake/help/v3.0/command/find_package.html -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From sjm324 at cornell.edu Wed Mar 21 15:12:01 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Wed, 21 Mar 2018 12:12:01 -0700 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> Message-ID: <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> Hi Mario, Do you get different results if you set CMAKE_MODULE_PATH rather than CMAKE_PREFIX_PATH? I wrote a tutorial for how to install a library called librealsense, at the very bottom is what will interest you: https://gist.github.com/svenevs/f00ed3898d2af6248921b63254aa8cc1#enable-librealsense-for-other-cmake-projects # Allow for `find_package(realsense2)` in CMake projects export CMAKE_MODULE_PATH="/opt/librealsense/lib/cmake${CMAKE_MODULE_PATH:+:${CMAKE_MODULE_PATH}}" This environment variable can either be set, or specified like you are doing with cmake .. -DCMAKE_MODULE_PATH=?/data/thirdparty?, noting that depending on where it got installed you may also need an extra lib on that path /data/thirdparty/lib I?m sure others on this list know the ?right? practice, but when CMAKE_INSTALL_PREFIX=/usr/local, it?s very common to see two possible install locations: /usr/local/cmake /usr/local/lib/cmake AKA just make sure that the zlib folder is a child directory. In the librealsense2 example, I have $ ls /opt/librealsense2/lib/cmake/ realsense2/ So since /opt/librealsense2/lib/cmake is in my CMAKE_MODULE_PATH, when I do find_package(realsense2), it will find that directory. I don?t know exactly what Zlib?s install looks like, and I know it matters whether they are using ?new? or ?old? cmake installation tactics, but hopefully this gets you closer to solving it! -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From miroslav.kes at gmail.com Wed Mar 21 15:16:54 2018 From: miroslav.kes at gmail.com (=?UTF-8?Q?Miroslav_Ke=c5=a1?=) Date: Wed, 21 Mar 2018 20:16:54 +0100 Subject: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling Message-ID: <08587f73-c14e-dda2-dc8a-2ef9b45cd136@gmail.com> Hi! I have question concerning the file(TO_NATIVE_PATH ...) behavior. The documentation says: "The TO_NATIVE_PATH mode converts a cmake-style into a native path with platform-specific slashes (\ on Windows and / elsewhere)." ?... but it doesn't say if the decision is made based on the CMAKE_SYSTEM_NAME or the CMAKE_HOST_SYSTEM_NAME variable. I have a project that builds the code for multiple platforms. The conversion works OK when building for Linux on Linux host or when building for Windows on a Windows host. But if I cross-compile on a Windows for a non-Windows platform, the file(TO_NATIVE_PATH ...) converts paths to the target "non Windows" platform convention. Is this the expected behavior? I was going to use it when calling external programs on the build host (e.g. to generate Doxygen config file from a template using configure_file() ). But it doesn't work because of the target host path convention output. Thanks. Mira From sjm324 at cornell.edu Wed Mar 21 15:34:37 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Wed, 21 Mar 2018 12:34:37 -0700 Subject: [CMake] Choosing SSE / AVX Flag Advice Message-ID: Hello, I was originally using -march=native for non-windows, but in my attempts to support embedded architectures learned that this flag is broken and/or does nothing for many compilers (fixed for ARM in gcc 8 I think though). Enter the glorious work of the folks at Vc: https://github.com/VcDevel/Vc/blob/master/cmake/OptimizeForArchitecture.cmake It?s quite comprehensive, and though it may not be ready for cross-compiling (still testing that, but I have to learn how to cross compile first!), it does appear to support native optimizations for embedded architectures. Here is my concern, the following flags are generated: -march=haswell;-msse2;-msse3;-mssse3;-msse4.1;-msse4.2;-mavx;-mfma;-mbmi2;-mavx2;-mno-sse4a;-mno-xop;-mno-fma4;-mno-avx512f;-mno-avx512vl;-mno-avx512pf;-mno-avx512er;-mno-avx512cd;-mno-avx512dq;-mno-avx512bw I am concerned only because these flags will be a part of the PUBLIC compile features of a library, Eigen is the main math library backend as well as there are some templated image conversion routines that use SSE2 intrinsics to operate in my library. Having that many additional flags could ultimately lead to undesirable consequences such as command line arguments being too long? I?m currently reworking it so that just the highest version (e.g. -mavx2) is used, but I?m not sure if I should even be worried about this. Thanks for any thoughts! -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Wed Mar 21 16:03:39 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Wed, 21 Mar 2018 13:03:39 -0700 Subject: [CMake] Advice on how to remove duplicated code for object and interface library setup In-Reply-To: <03344650-d96e-54bb-e768-e0464f3ee1ea@benocs.com> References: <89D0B121-F41A-4A4A-8A80-3C39F22B0D5B@cornell.edu> <03344650-d96e-54bb-e768-e0464f3ee1ea@benocs.com> Message-ID: <8B53535D-29CE-46CB-821B-0BA7F20F02DE@cornell.edu> Hi Deniz, Thanks for the response! I tested it out and it seems to work exactly as you describe :) I don?t want to depend on an un-released version of CMake though. The original desire is because I kept making mistakes / adding definitions for one and not the other (code duplication at its finest?). I discovered that I can populate one, e.g. only modify mylib_obj and then later grab these properties to add to the interface: get_target_property(MYLIB_OBJ_INTERFACE_COMPILE_DEFINITIONS mylib_obj INTERFACE_COMPILE_DEFINITIONS) and also the same for INTERFACE_COMPILE_OPTIONS etc. (Note: for anybody reading this, understand that INTERFACE_COMPILE_DEFINITIONS is desired here, COMPILE_DEFINITIONS includes private items which I do not want in this case). Is getting the properties and then later setting them a reasonable solution here, or is this a bad idea? -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Wed Mar 21 16:29:23 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Wed, 21 Mar 2018 13:29:23 -0700 Subject: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling In-Reply-To: <08587f73-c14e-dda2-dc8a-2ef9b45cd136@gmail.com> References: <08587f73-c14e-dda2-dc8a-2ef9b45cd136@gmail.com> Message-ID: <4FAA990D-C8EF-4FF1-9C71-A94E530A7156@cornell.edu> Disclaimer: I cannot speak to intent, and have never used these before. So since you?re cross compiling, when looking at the docs ( https://cmake.org/cmake/help/v3.0/command/file.html ), I think you can get away with using TO_CMAKE_PATH. I do not know how you actually determine this, but the idea would be if (CMAKE_CROSSCOMPILING) if (? host is windows ?) if (? target is unix ?) ? use TO_CMAKE_PATH ? else() ? use TO_NATIVE_PATH ? endif() else() # ? host is unix ? if (? target is unix ?) ? use TO_CMAKE_PATH or TO_NATIVE_PATH ? else() # ? target is windows ? PROBLEM ? endif() endif() That is, I think if you are compiling on Windows for Unix, you can cheat and use TO_CMAKE_PATH to get unix style paths. But if you are compiling on unix for Windows, I don?t know how you get it to be Windows paths. But if this does solve Windows -> Unix, you could maybe just message(FATAL_ERROR ?) saying that cross compiling for Windows from Unix is not supported. You could also take a look at the implementation of TO_NATIVE_PATH and just snag the Windows code and make your own function that converts it, maybe calling it to_windows_path() or something? I hope that is helpful, but I really don?t know if anything in the above is possible :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdamon at accesio.com Wed Mar 21 17:16:35 2018 From: jdamon at accesio.com (Jimi Damon) Date: Wed, 21 Mar 2018 14:16:35 -0700 Subject: [CMake] Cygwin DS-5 Arm Cross-compiling and how to get past Compiler Check error w/ Absolute path Message-ID: Hi, I have an issue running the 16.1 DS-5 Arm compiler tool suite that is based around the GNU arm embedded toolchain. The problem is that these compilers cannot process the Cygwin path structure ( Ie /cygdrive/c/....path/to/file ). I have a build that works perfectly under Linux using CMake and a CMAKE_TOOLCHAIN_FILE using this same DS-5 compiler build for Linux. The problem is that my teammates develop under Cygwin and I wanted to port this build (hence the reason for Cmake ) to Cygwin. 1. The first problem I have is that when I try to run cmake -DCMAKE_TOOLCHAIN_FILE=../../Toolchain-arm.cmake .. Is that Cmake tries to run testCCompiler.cc , but it uses the Cygwin absolute path to this file and fails. As a result my compiler errors out saying /cygdrive/c/intelFPGA/16.1/embedded/ds-5/sw/gcc/bin/arm-linux-gnueabihf-gcc -o CMakeFiles/cmTC_05821.dir/testCCompiler.c.obj -c /home/JDamon/device-mcb-apps/mavcore/build/CMakeFiles/CMakeTmp/testCCompiler.c arm-linux-gnueabihf-gcc.exe: error: /home/JDamon/device-mcb-apps/mavcore/build/CMakeFiles/CMakeTmp/testCCompiler.c: No such file or directory #< This is the indicator that it doesn't like Cygwin paths. You can verify this very easily just by creating a simple hello_world.c and run the compiler with the absolute path to that file. How can I get past this compiler check ? 2. Is there a way to force Cmake to use relative file names or Native file names ( something like TO_NATIVE_PATH ) when when performing the regular compilation ? I ask this because I already ran into the problem porting the manual Makefile from Linux to Cygwin and expressions like $(CC) -I/absolute/path/to/file ( rest of the line ) all failed because the compiler cannot handle the Cygwin paths. Thanks, -Jimi -- -- WARNING - This e-mail or its attachments may contain controlled technical data or controlled technology within the definition of the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR), and are subject to the export control laws of the U.S. Government. Transfer of this data or technology by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Government, is prohibited. The information contained in this document is CONFIDENTIAL and property of ACCES I/O Products, Inc. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of ACCES I/O Products, Inc. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marek.Vojtko at firaxis.com Wed Mar 21 19:41:32 2018 From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis)) Date: Wed, 21 Mar 2018 23:41:32 +0000 Subject: [CMake] Custom Configurations and CMAKE__FLAGS__INIT Message-ID: Hi, Do CMAKE__FLAGS__INIT variables not automatically populate CMAKE__FLAGS_ variables for *custom* configurations? When I use the _INIT variables for one of the default configuration names, e.g. CMAKE_C_FLAGS_DEBUG_INIT or CMAKE_C_FLAGS_RELEASE_INIT, they correctly populate their "usage" counterparts, i.e. CMAKE_C_FLAGS_DEBUG and CMAKE_C_FLAGS_RELEASE respectively. But when I set the _INIT variables for a custom configuration name (created through CMAKE_CONFIGURATION_TYPES), e.g. CMAKE_C_FLAGS_LALALAND_INIT, CMake fails the compiler tests, because CMAKE_C_FLAGS_LALALAND does not exist. My setup: *CMakeLists.txt* set( CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake" ) project( Test ) add_executable( "${CMAKE_CURRENT_LIST_DIR}/main.c" ) *CompilerOptions.cmake* set( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "Lalaland" ) set( CMAKE_C_FLAGS_DEBUG_INIT "/Od" ) set( CMAKE_C_FLAGS_RELEASE_INIT "/Ox" ) set( CMAKE_C_FLAGS_LALALAND_INIT "/Ob2" ) set( CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/machine:x64" ) set( CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "/machine:x64" ) set( CMAKE_EXE_LINKER_FLAGS_LALALAND_INIT "/machine:x64" ) The error I get is: > CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. > Missing variable is: > CMAKE_C_FLAGS_LALALAND > CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. > Missing variable is: > CMAKE_EXE_LINKER_FLAGS_LALALAND > CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:37 (try_compile): > Failed to generate test project build system. This is just a simplified example, in my actual usecase I have two custom configurations and both fail to populate their CMAKE__FLAGS_ variables from their CMAKE__FLAGS__INIT variables. Do I have to set the CMAKE__FLAGS__INIT variables for the default CMake configuration names, but set the actual CMAKE__FLAGS_ variables for any custom configurations? I am using CMake 3.10.3 and Visual Studio 11/14 Win64 generator. Thanks, Marek From kai.wolf at gmail.com Thu Mar 22 04:08:20 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Thu, 22 Mar 2018 09:08:20 +0100 Subject: [CMake] Adding ignored tests to CTest XML output Message-ID: Hi all, when adding some ignored tests into the CTestCustom.cmake file via the variable CTEST_CUSTOM_TESTS_IGNORE, I'd expect that those ignored tests will also be written into the XML output file generated by CTest, so that Jenkins or Teamcity is able to visualize this information. However, it seems that even though the tests are indeed not executed when running CTest, they're also not put into the XML file, for instance with . Is this behaviour expected or am I missing something? Thanks in advance Kai Wolf http://kai-wolf.me/ kai.wolf at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Thu Mar 22 04:41:47 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 22 Mar 2018 08:41:47 +0000 Subject: [CMake] find_package() for static only / shared only In-Reply-To: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> Message-ID: <609D870C-8266-421A-A3E8-8277CB500741@sap.com> Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. For example, on linux: * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so") * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a") On Windows, it is more problematic because static and "import" shared libraries have same extension: ".lib". But, if, by chance, you have different prefixes to distinguish them, you can rely on variable CMAKE_FIND_LIBRARY_PREFIXES to manage that. ?On 21/03/2018 10:56, "CMake on behalf of Mario Emmenlauer" wrote: I've googled this issue for a while now but found only few references (1,2) and no solution. I'd like to enforce that find_package() will only accept static or shared libraries. I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). I.e. I'd love to have something like: if(BUILD_SHARED_LIBS) BUILD_TYPE="SHARED" else() BUILD_TYPE="STATIC" endif() find_package(XXX ${BUILD_TYPE}) find_package(YYY ${BUILD_TYPE}) find_package(ZZZ ${BUILD_TYPE}) ... It seems that this does not exist? I could also not find a good workaround. The best I can find is to use 'NAMES' and add the static or shared library names manually. This is not very suitable, because I have a project with more than 30 dependencies. The project should either build (fully) static or (fully) shared. I can not easily maintain lists of 30 static and shared library names on several platforms. Is there a solution or good workaround? All the best, Mario Emmenlauer (1) https://cmake.org/pipermail/cmake/2012-September/052059.html (2) https://cmake.org/pipermail/cmake/2010-December/041326.html -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ -- 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 From mario at emmenlauer.de Thu Mar 22 07:14:49 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Thu, 22 Mar 2018 12:14:49 +0100 Subject: [CMake] find_package() for static only / shared only In-Reply-To: <609D870C-8266-421A-A3E8-8277CB500741@sap.com> References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> <609D870C-8266-421A-A3E8-8277CB500741@sap.com> Message-ID: <7282a187-c18d-7933-e19e-751e696b0ebb@emmenlauer.de> Dear Marc, this is a pretty neat idea! Let me quickly recapitulate: the library prefixes and suffixes for multiple platforms are: | static | shared | prefix | suffix | prefix | suffix --------------------------------------------------------------------- Linux | lib | .a | lib | .so MacOSX | lib | .a | lib | .dylib MinGW | lib | .a | lib | .dll.a/.dll MSVC | - | .lib | - | .lib/.dll Is that about correct? So it should work mostly everywhere with the note- worthy exception of MSVC, where the shared import library is not easily discriminated from the static library. Is there a good solution for MSVC too? All the best, Mario On 22.03.2018 09:41, CHEVRIER, Marc wrote: > Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. > For example, on linux: > * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so") > * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a") > > On Windows, it is more problematic because static and "import" shared libraries have same extension: ".lib". > But, if, by chance, you have different prefixes to distinguish them, you can rely on variable CMAKE_FIND_LIBRARY_PREFIXES to manage that. > > > ?On 21/03/2018 10:56, "CMake on behalf of Mario Emmenlauer" wrote: > > > I've googled this issue for a while now but found only few > references (1,2) and no solution. I'd like to enforce that > find_package() will only accept static or shared libraries. > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). > > I.e. I'd love to have something like: > if(BUILD_SHARED_LIBS) > BUILD_TYPE="SHARED" > else() > BUILD_TYPE="STATIC" > endif() > find_package(XXX ${BUILD_TYPE}) > find_package(YYY ${BUILD_TYPE}) > find_package(ZZZ ${BUILD_TYPE}) > ... > > > It seems that this does not exist? I could also not find a > good workaround. The best I can find is to use 'NAMES' and > add the static or shared library names manually. > > This is not very suitable, because I have a project with more > than 30 dependencies. The project should either build (fully) > static or (fully) shared. I can not easily maintain lists of > 30 static and shared library names on several platforms. > > Is there a solution or good workaround? > > All the best, > > Mario Emmenlauer > > > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 M?nchen http://www.biodataanalysis.de/ > -- > > 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 > > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From marc.chevrier at sap.com Thu Mar 22 07:22:15 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 22 Mar 2018 11:22:15 +0000 Subject: [CMake] find_package() for static only / shared only In-Reply-To: <7282a187-c18d-7933-e19e-751e696b0ebb@emmenlauer.de> References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> <609D870C-8266-421A-A3E8-8277CB500741@sap.com> <7282a187-c18d-7933-e19e-751e696b0ebb@emmenlauer.de> Message-ID: <2E64F083-30F5-4EEF-9027-778B1DCEF02D@sap.com> Yes. Seems OK. For Windows, if libraries are all your owns, you can manage this by relaying on a specific prefix for static libraries. A commonly adopted naming is to add prefix "lib" for static libraries. Now, if you add to rely on external libraries, I don't see any general solution. ?On 22/03/2018 12:15, "Mario Emmenlauer" wrote: Dear Marc, this is a pretty neat idea! Let me quickly recapitulate: the library prefixes and suffixes for multiple platforms are: | static | shared | prefix | suffix | prefix | suffix --------------------------------------------------------------------- Linux | lib | .a | lib | .so MacOSX | lib | .a | lib | .dylib MinGW | lib | .a | lib | .dll.a/.dll MSVC | - | .lib | - | .lib/.dll Is that about correct? So it should work mostly everywhere with the note- worthy exception of MSVC, where the shared import library is not easily discriminated from the static library. Is there a good solution for MSVC too? All the best, Mario On 22.03.2018 09:41, CHEVRIER, Marc wrote: > Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. > For example, on linux: > * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so") > * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a") > > On Windows, it is more problematic because static and "import" shared libraries have same extension: ".lib". > But, if, by chance, you have different prefixes to distinguish them, you can rely on variable CMAKE_FIND_LIBRARY_PREFIXES to manage that. > > > On 21/03/2018 10:56, "CMake on behalf of Mario Emmenlauer" wrote: > > > I've googled this issue for a while now but found only few > references (1,2) and no solution. I'd like to enforce that > find_package() will only accept static or shared libraries. > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). > > I.e. I'd love to have something like: > if(BUILD_SHARED_LIBS) > BUILD_TYPE="SHARED" > else() > BUILD_TYPE="STATIC" > endif() > find_package(XXX ${BUILD_TYPE}) > find_package(YYY ${BUILD_TYPE}) > find_package(ZZZ ${BUILD_TYPE}) > ... > > > It seems that this does not exist? I could also not find a > good workaround. The best I can find is to use 'NAMES' and > add the static or shared library names manually. > > This is not very suitable, because I have a project with more > than 30 dependencies. The project should either build (fully) > static or (fully) shared. I can not easily maintain lists of > 30 static and shared library names on several platforms. > > Is there a solution or good workaround? > > All the best, > > Mario Emmenlauer > > > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 M?nchen http://www.biodataanalysis.de/ > -- > > 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 > > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From mario at emmenlauer.de Thu Mar 22 07:42:49 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Thu, 22 Mar 2018 12:42:49 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> Message-ID: Dear Stephen, thanks for your great help, I certainly learned something! But for my current problem, zlib generally uses autotools to build, and the find_package(ZLIB) is in my case looking for the library, not the cmake config. Would your idea of CMAKE_MODULE_PATH apply to that? All the best, Mario On 21.03.2018 20:12, Stephen McDowell wrote: > Hi Mario, > > Do you get different results if you set CMAKE_MODULE_PATH rather than CMAKE_PREFIX_PATH? ?I wrote a tutorial for how to install a library called librealsense, > at the very bottom is what will interest you: > > https://gist.github.com/svenevs/f00ed3898d2af6248921b63254aa8cc1#enable-librealsense-for-other-cmake-projects > > # Allow for `find_package(realsense2)` in CMake projects > export CMAKE_MODULE_PATH="/opt/librealsense/lib/cmake${CMAKE_MODULE_PATH:+:${CMAKE_MODULE_PATH}}" > > > This environment variable can either be set, or specified like you are doing with cmake .. -DCMAKE_MODULE_PATH=?/data/thirdparty?, *noting*?that depending on > where it got installed you may also need an extra *lib*?on that path > > ? ? /data/thirdparty/*lib* > * > * > I?m sure others on this list know the ?right? practice, but when CMAKE_INSTALL_PREFIX=/usr/local, it?s very common to see two possible install locations: > > ? ? /usr/local/cmake > ? ? /usr/local/lib/cmake > > AKA just make sure that the zlib folder is a child directory. ?In the librealsense2 example, I have > > ? ? $ ls /opt/librealsense2/lib/cmake/ > ? ? realsense2/ > > So since /opt/librealsense2/lib/cmake is in my CMAKE_MODULE_PATH, when I do find_package(realsense2), it will find that directory. > > I don?t know exactly what Zlib?s install looks like, and I know it matters whether they are using ?new? or ?old? cmake installation tactics, but hopefully this > gets you closer to solving it! > > -Stephen > > > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From mateusz at loskot.net Thu Mar 22 10:17:15 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 22 Mar 2018 15:17:15 +0100 Subject: [CMake] [proposal] Support for modern CMake In-Reply-To: <84534259.EJmlnaiSMg@linux-l7nd> References: <84534259.EJmlnaiSMg@linux-l7nd> Message-ID: On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. It seems folks generally agree there is need for porcelain API. It's a pity it's been 5+ years and it is still waiting for implementation. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From brad.king at kitware.com Thu Mar 22 11:51:11 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 22 Mar 2018 11:51:11 -0400 Subject: [CMake] [proposal] Support for modern CMake In-Reply-To: References: <84534259.EJmlnaiSMg@linux-l7nd> Message-ID: On 03/22/2018 10:17 AM, Mateusz Loskot wrote: > It seems folks generally agree there is need for porcelain API. > It's a pity it's been 5+ years and it is still waiting for implementation. For reference, there were several discussions. Some of them were here: * "Setting include directories via target_link_libraries" https://cmake.org/pipermail/cmake-developers/2012-December/017561.html * "Setting includes, defines and other usage requirements with one command" https://cmake.org/pipermail/cmake-developers/2013-January/017939.html It was an extended debate over whether a separate `target_use_targets` command should be introduced instead of propagating usage requirements through `target_link_libraries`. The main driving factor was compatibility with existing projects using `target_link_libraries` at the time. In the end it was decided that the extra command would be redundant and we proceeded with `tll()` only. I'd prefer not to have this debated endlessly again. Perhaps the name `target_link_libraries` no longer fully conveys the semantics, but it's good enough and has worked well for years now. -Brad From mateusz at loskot.net Thu Mar 22 12:16:38 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 22 Mar 2018 17:16:38 +0100 Subject: [CMake] [proposal] Support for modern CMake In-Reply-To: References: <84534259.EJmlnaiSMg@linux-l7nd> Message-ID: On 22 March 2018 at 16:51, Brad King wrote: > On 03/22/2018 10:17 AM, Mateusz Loskot wrote: >> It seems folks generally agree there is need for porcelain API. >> It's a pity it's been 5+ years and it is still waiting for implementation. > > [...] > The main driving factor was compatibility with existing projects > using `target_link_libraries` at the time. I could have an argument to that... > In the end it was decided that the extra command would be redundant and > we proceeded with `tll()` only. I'd prefer not to have this debated > endlessly again. ...but I won't and I'll shut up then. Thank you for chiming in with the extra details. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From sjm324 at cornell.edu Thu Mar 22 12:43:21 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Thu, 22 Mar 2018 09:43:21 -0700 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> Message-ID: Hi Mario, Very sorry, I should have looked more closely! CMAKE_MODULE_PATH is for libraries that install their own CMake scripts. You are correct, Zlib only installs a pkg-config script. However, FindZLIB.cmake doesn?t appear to use that at all (aka I don?t believe you need to be setting PKG_CONFIG_PATH). You should be able to get away with setting ZLIB_ROOT. So for you I think it would look like cmake .. -DZLIB_ROOT=/data/thirdparty FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library. The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ). These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically because the library uses a different build system such as autotools). - - - - - If you are still having trouble, this is what I used to test this. I didn?t actually write code that uses it, but I suspect if you remove setting of CMAKE_PREFIX_PATH (I think that?s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!). With a very crude CMakeLists.txt: cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project("find_zlib") find_package(ZLIB) if (ZLIB_FOUND) message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}") else() message(FATAL_ERROR "Did not find Zlib :/") endif() Without setting ZLIB_ROOT: $ cmake .. -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") CMake Error at CMakeLists.txt:6 (message): Found Zlib: - ZLIB_INCLUDE_DIRS: /usr/include - ZLIB_LIBRARIES: /usr/lib/libz.dylib That?s the default Zlib that comes with OS X. However, if I specify ZLIB_ROOT: $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/ -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11") CMake Error at CMakeLists.txt:6 (message): Found Zlib: - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib Let us know if it works or if you still need help! -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Thu Mar 22 12:54:42 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Thu, 22 Mar 2018 17:54:42 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> Message-ID: <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Dear Stephen, thanks a lot for your support! I've tested and your suggestion works! But, it does not fully resolve my pain :-( I'm slightly scared now because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH is searched first (1). That aspect is quite crucial to me, because I have patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH. If I can not rely that cmake would use the patched versions, then I may end up having an "interesting" mix of system and patched libraries in my executable :-( (1) https://cmake.org/cmake/help/v3.0/command/find_package.html Thanks a lot and all the best, Mario On 22.03.2018 17:43, Stephen McDowell wrote: > Hi Mario, > > Very sorry, I should have looked more closely! ?CMAKE_MODULE_PATH is for libraries that install their own CMake scripts. ?You are correct, Zlib only installs a > pkg-config script. ?However, FindZLIB.cmake doesn?t appear to use that at all (aka I don?t believe you /need/ to be setting PKG_CONFIG_PATH). ?You should be > able to get away with setting *ZLIB_ROOT*. ?So for you I think it would look like > > ? ? cmake .. -DZLIB_ROOT=/data/thirdparty > > FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library. > > The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom:?https://cmake.org/cmake/help/v3.0/module/FindZLIB.html?). > ?These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically > because the library uses a different build system such as autotools). > > - - - - - > > If you are still having trouble, this is what I used to test this. ?I didn?t actually write code that uses it, but I suspect if you *remove*?setting of > CMAKE_PREFIX_PATH (I think that?s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!). > > With a very crude CMakeLists.txt: > > ? ? cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > ? ? project("find_zlib") > > ? ? find_package(ZLIB) > ? ? if (ZLIB_FOUND) > ? ? ? message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}") > ? ? else() > ? ? ? message(FATAL_ERROR "Did not find Zlib :/") > ? ? endif() > > *Without* setting ZLIB_ROOT: > > ? ? $ cmake .. > ? ? -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") > ? ? CMake Error at CMakeLists.txt:6 (message): > ? ? ? Found Zlib: > ? ? ? - ZLIB_INCLUDE_DIRS: /usr/include > ? ? ? - ZLIB_LIBRARIES: /usr/lib/libz.dylib > > That?s the default Zlib that comes with OS X. ?However, if I specify ZLIB_ROOT: > > ? ? $?cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/ > ? ? -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11") > ? ? CMake Error at CMakeLists.txt:6 (message): > ? ? ? Found Zlib: > ? ? ? - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include > ? ? ? - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib > > Let us know if it works or if you still need help! > > -Stephen > > > -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From sjm324 at cornell.edu Thu Mar 22 13:46:22 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Thu, 22 Mar 2018 10:46:22 -0700 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: <1904482A-FAC4-4744-A2D8-7A0238903A52@cornell.edu> That?s progress though? :) Hmmm. I understand your problem now, but I don?t know how to fix it. You can do things like find_package(ZLIB NO_DEFAULT_PATH) That makes it so the system Zlib won?t be found, but I couldn?t then get `cmake .. -DZLIB_ROOT=xxx` to work :/ There are other NO_* variables mentioned on that page too, maybe one of those and setting CMAKE_PREFIX_PATH could work? I?m not familiar with these path variables in CMake? From zack.galbreath at kitware.com Thu Mar 22 16:49:11 2018 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 22 Mar 2018 16:49:11 -0400 Subject: [CMake] Adding ignored tests to CTest XML output In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 4:08 AM, Kai Wolf wrote: > when adding some ignored tests into the CTestCustom.cmake file via the > variable CTEST_CUSTOM_TESTS_IGNORE, I'd expect that those ignored tests > will also be written into the XML output file generated by CTest, so that > Jenkins or Teamcity is able to visualize this information. > > However, it seems that even though the tests are indeed not executed when > running CTest, they're also not put into the XML file, for instance with > . Is this behaviour expected or am I missing > something? > You can use set_tests_properties to mark a test as DISABLED . Disabled tests are included in your Test.xml file, and they are shown on CDash as a slightly different flavor of "not run" test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marek.Vojtko at firaxis.com Thu Mar 22 19:10:09 2018 From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis)) Date: Thu, 22 Mar 2018 23:10:09 +0000 Subject: [CMake] Custom Configurations and CMAKE__FLAGS__INIT Message-ID: It turns out, as of CMake 3.11, this works. Thanks to Beren Minor's commit 48f7e2d3, CMake 3.11 has a new CMakeInitializeConfigs.cmake module that handles all _INIT variables, even custom configuration ones, correctly. Yay! [0] https://gitlab.kitware.com/cmake/cmake/commit/48f7e2d30000dc57c31d3e3ab81077950704a587 > Hi, > > Do CMAKE__FLAGS__INIT variables not automatically populate CMAKE__FLAGS_ variables for *custom* > configurations? > > When I use the _INIT variables for one of the default configuration names, e.g. CMAKE_C_FLAGS_DEBUG_INIT or > CMAKE_C_FLAGS_RELEASE_INIT, they correctly populate their "usage" counterparts, i.e. CMAKE_C_FLAGS_DEBUG and > CMAKE_C_FLAGS_RELEASE respectively. > > But when I set the _INIT variables for a custom configuration name (created through CMAKE_CONFIGURATION_TYPES), e.g. > CMAKE_C_FLAGS_LALALAND_INIT, CMake fails the compiler tests, because CMAKE_C_FLAGS_LALALAND does not exist. > > My setup: > > *CMakeLists.txt* > set( CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake" ) > project( Test ) > add_executable( "${CMAKE_CURRENT_LIST_DIR}/main.c" ) > > *CompilerOptions.cmake* > set( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "Lalaland" ) > > set( CMAKE_C_FLAGS_DEBUG_INIT "/Od" ) > set( CMAKE_C_FLAGS_RELEASE_INIT "/Ox" ) > set( CMAKE_C_FLAGS_LALALAND_INIT "/Ob2" ) > > set( CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/machine:x64" ) > set( CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "/machine:x64" ) > set( CMAKE_EXE_LINKER_FLAGS_LALALAND_INIT "/machine:x64" ) > > The error I get is: > > > CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. > > Missing variable is: > > CMAKE_C_FLAGS_LALALAND > > > CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. > > Missing variable is: > > CMAKE_EXE_LINKER_FLAGS_LALALAND > > > CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:37 (try_compile): > > Failed to generate test project build system. > > This is just a simplified example, in my actual usecase I have two custom configurations and both fail to populate their > CMAKE__FLAGS_ variables from their CMAKE__FLAGS__INIT variables. > > Do I have to set the CMAKE__FLAGS__INIT variables for the default CMake configuration names, but set the > actual CMAKE__FLAGS_ variables for any custom configurations? > > I am using CMake 3.10.3 and Visual Studio 11/14 Win64 generator. > > Thanks, > Marek From pfultz2 at yahoo.com Thu Mar 22 19:52:49 2018 From: pfultz2 at yahoo.com (P F) Date: Thu, 22 Mar 2018 18:52:49 -0500 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: Are you setting `CMAKE_INSTALL_PREFIX`? This path is searched before the `CMAKE_PREFIX_PATH` is searched. Also the find_package paths listed in the documentation are only for libraries that provide find_package support. Zlib does not, so it cmake fallsback on the FindZLIB.cmake module to do the searching which the search order can be entirely up to the author of the module. You can see how FindZLIB.cmake searches here: https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L72 Of course, if its not correctly searching the `CMAKE_PREFIX_PATH` then this should be considered a bug. > On Mar 22, 2018, at 11:54 AM, Mario Emmenlauer > wrote: > > > Dear Stephen, > > thanks a lot for your support! I've tested and your suggestion works! > > But, it does not fully resolve my pain :-( I'm slightly scared now > because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system > libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH > is searched first (1). That aspect is quite crucial to me, because I have > patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH. > If I can not rely that cmake would use the patched versions, then I > may end up having an "interesting" mix of system and patched libraries > in my executable :-( > > (1) https://cmake.org/cmake/help/v3.0/command/find_package.html > > Thanks a lot and all the best, > > Mario > > > On 22.03.2018 17:43, Stephen McDowell wrote: >> Hi Mario, >> >> Very sorry, I should have looked more closely! CMAKE_MODULE_PATH is for libraries that install their own CMake scripts. You are correct, Zlib only installs a >> pkg-config script. However, FindZLIB.cmake doesn?t appear to use that at all (aka I don?t believe you /need/ to be setting PKG_CONFIG_PATH). You should be >> able to get away with setting *ZLIB_ROOT*. So for you I think it would look like >> >> cmake .. -DZLIB_ROOT=/data/thirdparty >> >> FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library. >> >> The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ). >> These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically >> because the library uses a different build system such as autotools). >> >> - - - - - >> >> If you are still having trouble, this is what I used to test this. I didn?t actually write code that uses it, but I suspect if you *remove* setting of >> CMAKE_PREFIX_PATH (I think that?s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!). >> >> With a very crude CMakeLists.txt: >> >> cmake_minimum_required(VERSION 3.0 FATAL_ERROR) >> project("find_zlib") >> >> find_package(ZLIB) >> if (ZLIB_FOUND) >> message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}") >> else() >> message(FATAL_ERROR "Did not find Zlib :/") >> endif() >> >> *Without* setting ZLIB_ROOT: >> >> $ cmake .. >> -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") >> CMake Error at CMakeLists.txt:6 (message): >> Found Zlib: >> - ZLIB_INCLUDE_DIRS: /usr/include >> - ZLIB_LIBRARIES: /usr/lib/libz.dylib >> >> That?s the default Zlib that comes with OS X. However, if I specify ZLIB_ROOT: >> >> $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/ >> -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11") >> CMake Error at CMakeLists.txt:6 (message): >> Found Zlib: >> - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include >> - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib >> >> Let us know if it works or if you still need help! >> >> -Stephen >> >> >> > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 M?nchen http://www.biodataanalysis.de/ > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Thu Mar 22 19:57:45 2018 From: pfultz2 at yahoo.com (P F) Date: Thu, 22 Mar 2018 18:57:45 -0500 Subject: [CMake] find_package() for static only / shared only In-Reply-To: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> Message-ID: Why not install shared libraries in one location and static libraries in another? > On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer wrote: > > > I've googled this issue for a while now but found only few > references (1,2) and no solution. I'd like to enforce that > find_package() will only accept static or shared libraries. > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). > > I.e. I'd love to have something like: > if(BUILD_SHARED_LIBS) > BUILD_TYPE="SHARED" > else() > BUILD_TYPE="STATIC" > endif() > find_package(XXX ${BUILD_TYPE}) > find_package(YYY ${BUILD_TYPE}) > find_package(ZZZ ${BUILD_TYPE}) > ... > > > It seems that this does not exist? I could also not find a > good workaround. The best I can find is to use 'NAMES' and > add the static or shared library names manually. > > This is not very suitable, because I have a project with more > than 30 dependencies. The project should either build (fully) > static or (fully) shared. I can not easily maintain lists of > 30 static and shared library names on several platforms. > > Is there a solution or good workaround? > > All the best, > > Mario Emmenlauer > > > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 M?nchen http://www.biodataanalysis.de/ > -- > > 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 From mingw.android at gmail.com Thu Mar 22 22:14:53 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Fri, 23 Mar 2018 02:14:53 +0000 Subject: [CMake] find_package() for static only / shared only In-Reply-To: References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> Message-ID: Our why doesn't cmake set a long needed standard here of .dll.lib and be done with this nonsense? On Thu, Mar 22, 2018, 11:58 PM P F via CMake wrote: > Why not install shared libraries in one location and static libraries in > another? > > > On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer > wrote: > > > > > > I've googled this issue for a while now but found only few > > references (1,2) and no solution. I'd like to enforce that > > find_package() will only accept static or shared libraries. > > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). > > > > I.e. I'd love to have something like: > > if(BUILD_SHARED_LIBS) > > BUILD_TYPE="SHARED" > > else() > > BUILD_TYPE="STATIC" > > endif() > > find_package(XXX ${BUILD_TYPE}) > > find_package(YYY ${BUILD_TYPE}) > > find_package(ZZZ ${BUILD_TYPE}) > > ... > > > > > > It seems that this does not exist? I could also not find a > > good workaround. The best I can find is to use 'NAMES' and > > add the static or shared library names manually. > > > > This is not very suitable, because I have a project with more > > than 30 dependencies. The project should either build (fully) > > static or (fully) shared. I can not easily maintain lists of > > 30 static and shared library names on several platforms. > > > > Is there a solution or good workaround? > > > > All the best, > > > > Mario Emmenlauer > > > > > > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html > > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html > > > > > > -- > > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > > D-81669 M?nchen http://www.biodataanalysis.de/ > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Fri Mar 23 05:21:58 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Fri, 23 Mar 2018 10:21:58 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: Thanks PF, I think this makes more sense now! I was assuming that cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you clarified, that only applies to libraries that provide find_package support. This is actually quite unfortunate. Then I don't see an easy way to enforce usage of specific libs. As an example, if I want to enforce a patched libtiff (that does not itself provide find_package support) the only "safe" way is to replace the system libtiff. Otherwise any package might just find the system version first without me even knowing. This actually opens quite a can of worms :-( All the best, Mario On 23.03.2018 00:52, P F wrote: > Are you setting `CMAKE_INSTALL_PREFIX`? This path is searched before the `CMAKE_PREFIX_PATH` is searched.? > > Also the find_package paths listed in the documentation are only for libraries that provide find_package support. Zlib does not, so it cmake fallsback on the > FindZLIB.cmake module to do the searching which the search order can be entirely up to the author of the module. You can see how FindZLIB.cmake searches here: > > https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L72 > > Of course, if its not correctly searching the `CMAKE_PREFIX_PATH` then this should be considered a bug. > >> On Mar 22, 2018, at 11:54 AM, Mario Emmenlauer > wrote: >> >> >> Dear Stephen, >> >> thanks a lot for your support! I've tested and your suggestion works! >> >> But, it does not fully resolve my pain :-( I'm slightly scared now >> because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system >> libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH >> is searched first (1). That aspect is quite crucial to me, because I have >> patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH. >> If I can not rely that cmake would use the patched versions, then I >> may end up having an "interesting" mix of system and patched libraries >> in my executable :-( >> >> (1)?https://cmake.org/cmake/help/v3.0/command/find_package.html >> >> Thanks a lot and all the best, >> >> ???Mario >> >> >> On 22.03.2018 17:43, Stephen McDowell wrote: >>> Hi Mario, >>> >>> Very sorry, I should have looked more closely! ?CMAKE_MODULE_PATH is for libraries that install their own CMake scripts. ?You are correct, Zlib only installs a >>> pkg-config script. ?However, FindZLIB.cmake doesn?t appear to use that at all (aka I don?t believe you /need/ to be setting PKG_CONFIG_PATH). ?You should be >>> able to get away with setting *ZLIB_ROOT*. ?So for you I think it would look like >>> >>> ? ??cmake .. -DZLIB_ROOT=/data/thirdparty >>> >>> FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library. >>> >>> The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html?). >>> ?These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically >>> because the library uses a different build system such as autotools). >>> >>> - - - - - >>> >>> If you are still having trouble, this is what I used to test this. ?I didn?t actually write code that uses it, but I suspect if you *remove*?setting of >>> CMAKE_PREFIX_PATH (I think that?s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!). >>> >>> With a very crude CMakeLists.txt: >>> >>> ? ??cmake_minimum_required(VERSION 3.0 FATAL_ERROR) >>> ? ??project("find_zlib") >>> >>> ? ??find_package(ZLIB) >>> ? ??if (ZLIB_FOUND) >>> ? ? ??message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}") >>> ? ??else() >>> ? ? ??message(FATAL_ERROR "Did not find Zlib :/") >>> ? ??endif() >>> >>> *Without* setting ZLIB_ROOT: >>> >>> ? ??$ cmake .. >>> ? ??-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") >>> ? ??CMake Error at CMakeLists.txt:6 (message): >>> ? ? ??Found Zlib: >>> ? ? ??- ZLIB_INCLUDE_DIRS: /usr/include >>> ? ? ??- ZLIB_LIBRARIES: /usr/lib/libz.dylib >>> >>> That?s the default Zlib that comes with OS X. ?However, if I specify ZLIB_ROOT: >>> >>> ? ??$?cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/ >>> ? ??-- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11") >>> ? ??CMake Error at CMakeLists.txt:6 (message): >>> ? ? ??Found Zlib: >>> ? ? ??- ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include >>> ? ? ??- ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib >>> >>> Let us know if it works or if you still need help! >>> >>> -Stephen Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From mario at emmenlauer.de Fri Mar 23 05:24:10 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Fri, 23 Mar 2018 10:24:10 +0100 Subject: [CMake] find_package() for static only / shared only In-Reply-To: References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> Message-ID: <46fc4dd4-6614-e4cf-8265-3388386a713d@emmenlauer.de> Dear PF, thanks! I think this is a quite sensible approach and I will do as you suggest. I did not consider it at first because there are some packages that can install static and shared side-by-side. But I agree that your suggestion is ore pragmatic and also less error-prone. All the best, Mario On 23.03.2018 00:57, P F wrote: > Why not install shared libraries in one location and static libraries in another? > >> On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer wrote: >> >> >> I've googled this issue for a while now but found only few >> references (1,2) and no solution. I'd like to enforce that >> find_package() will only accept static or shared libraries. >> I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). >> >> I.e. I'd love to have something like: >> if(BUILD_SHARED_LIBS) >> BUILD_TYPE="SHARED" >> else() >> BUILD_TYPE="STATIC" >> endif() >> find_package(XXX ${BUILD_TYPE}) >> find_package(YYY ${BUILD_TYPE}) >> find_package(ZZZ ${BUILD_TYPE}) >> ... >> >> >> It seems that this does not exist? I could also not find a >> good workaround. The best I can find is to use 'NAMES' and >> add the static or shared library names manually. >> >> This is not very suitable, because I have a project with more >> than 30 dependencies. The project should either build (fully) >> static or (fully) shared. I can not easily maintain lists of >> 30 static and shared library names on several platforms. >> >> Is there a solution or good workaround? >> >> All the best, >> >> Mario Emmenlauer >> >> >> (1) https://cmake.org/pipermail/cmake/2012-September/052059.html >> (2) https://cmake.org/pipermail/cmake/2010-December/041326.html >> >> >> -- >> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 >> Balanstr. 43 mailto: memmenlauer * biodataanalysis.de >> D-81669 M?nchen http://www.biodataanalysis.de/ >> -- >> >> 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 > > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From mario at emmenlauer.de Fri Mar 23 05:26:43 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Fri, 23 Mar 2018 10:26:43 +0100 Subject: [CMake] find_package() for static only / shared only In-Reply-To: References: <52e57479-26e1-7e0b-7eb4-94b09a9e608d@emmenlauer.de> Message-ID: Two thumbs up for this! :-) On 23.03.2018 03:14, Ray Donnelly wrote: > Our why doesn't cmake set a long needed standard here of .dll.lib and be done with this nonsense? > > On Thu, Mar 22, 2018, 11:58 PM P F via CMake > wrote: > > Why not install shared libraries in one location and static libraries in another? > > > On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer > wrote: > > > > > > I've googled this issue for a while now but found only few > > references (1,2) and no solution. I'd like to enforce that > > find_package() will only accept static or shared libraries. > > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF). > > > > I.e. I'd love to have something like: > >? ? if(BUILD_SHARED_LIBS) > >? ? ? ? BUILD_TYPE="SHARED" > >? ? else() > >? ? ? ? BUILD_TYPE="STATIC" > >? ? endif() > >? ? find_package(XXX ${BUILD_TYPE}) > >? ? find_package(YYY ${BUILD_TYPE}) > >? ? find_package(ZZZ ${BUILD_TYPE}) > >? ? ... > > > > > > It seems that this does not exist? I could also not find a > > good workaround. The best I can find is to use 'NAMES' and > > add the static or shared library names manually. > > > > This is not very suitable, because I have a project with more > > than 30 dependencies. The project should either build (fully) > > static or (fully) shared. I can not easily maintain lists of > > 30 static and shared library names on several platforms. > > > > Is there a solution or good workaround? > > > > All the best, > > > >? ? Mario Emmenlauer > > > > > > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html > > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html > > > > > > -- > > BioDataAnalysis GmbH, Mario Emmenlauer? ? ? Tel. Buero: +49-89-74677203 > > Balanstr. 43? ? ? ? ? ? ? ? ? ?mailto: memmenlauer * biodataanalysis.de > > D-81669 M?nchen? ? ? ? ? ? ? ? ? ? ? ? ? http://www.biodataanalysis.de/ > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From realnc at gmail.com Fri Mar 23 05:31:06 2018 From: realnc at gmail.com (Nikos Chantziaras) Date: Fri, 23 Mar 2018 11:31:06 +0200 Subject: [CMake] Suppressing LINK_WHAT_YOU_USE warning Message-ID: When using the LINK_WHAT_YOU_USE feature to detect unneeded library dependencies in a C++ project, I get this: Unused direct dependencies: /lib64/libm.so.6 It seems CMake should be smart enough to suppress this, as it doesn't seem possible to not link against libm? Is there a way to suppress this warning? Or a way to not link against libm? From eric.noulard at gmail.com Fri Mar 23 05:58:51 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 23 Mar 2018 10:58:51 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer : > > Thanks PF, I think this makes more sense now! I was assuming that > cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you > clarified, that only applies to libraries that provide find_package > support. > > This is actually quite unfortunate. Then I don't see an easy way to > enforce usage of specific libs. As an example, if I want to enforce a > patched libtiff (that does not itself provide find_package support) > the only "safe" way is to replace the system libtiff. Otherwise any > package might just find the system version first without me even > knowing. > You can always ship your own/patched version of Find.cmake module with your project source and build the 'local' override logic in it for every project/lib that does not provide a find_package. Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH) something like: list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake) before using find_package etc... I find it a "safer" solution than system lib replacement. My opinion though. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Fri Mar 23 06:44:11 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Fri, 23 Mar 2018 11:44:11 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: Hi Eric, On 23.03.2018 10:58, Eric Noulard wrote: > 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer >: > > > Thanks PF, I think this makes more sense now! I was assuming that > cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you > clarified, that only applies to libraries that provide find_package > support. > > This is actually quite unfortunate. Then I don't see an easy way to > enforce usage of specific libs. As an example, if I want to enforce a > patched libtiff (that does not itself provide find_package support) > the only "safe" way is to replace the system libtiff. Otherwise any > package might just find the system version first without me even > knowing. > > > You can always ship your own/patched version of? Find.cmake module with your > project source and build the 'local' override logic in it for every project/lib that does not provide a find_package. > > Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH) > > something like: > ?list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake) > > before using find_package etc... > > I find it a "safer" solution than system lib replacement. > My opinion though. I was considering this option too. But in my original email I outlined that this is not only for my own package, but additionally for more than 30 thirdparty dependencies. So its not only about ensuring that my packages use the correct thirdparty version, furthermore the packages themselves have inter-dependencies that must be correctly resolved. So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG, FindPROJ4, FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty dependencies. It would create a maintenance hell :-( How are other people resolving this? All the best, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From eric.noulard at gmail.com Fri Mar 23 07:00:09 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 23 Mar 2018 12:00:09 +0100 Subject: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused? In-Reply-To: References: <6c77a60f-448a-8226-535c-9295b8965513@emmenlauer.de> <1DDABD58-CC5D-4848-AEC1-DADBA9A9A853@cornell.edu> <38261e81-638c-d8d1-b607-cca014777cda@emmenlauer.de> Message-ID: 2018-03-23 11:44 GMT+01:00 Mario Emmenlauer : > > Hi Eric, > > On 23.03.2018 10:58, Eric Noulard wrote: > > 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer >: > > > > > > Thanks PF, I think this makes more sense now! I was assuming that > > cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you > > clarified, that only applies to libraries that provide find_package > > support. > > > > This is actually quite unfortunate. Then I don't see an easy way to > > enforce usage of specific libs. As an example, if I want to enforce a > > patched libtiff (that does not itself provide find_package support) > > the only "safe" way is to replace the system libtiff. Otherwise any > > package might just find the system version first without me even > > knowing. > > > > > > You can always ship your own/patched version of Find.cmake > module with your > > project source and build the 'local' override logic in it for every > project/lib that does not provide a find_package. > > > > Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH) > > > > something like: > > list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake) > > > > before using find_package etc... > > > > I find it a "safer" solution than system lib replacement. > > My opinion though. > > I was considering this option too. But in my original email I outlined > that this is not only for my own package, but additionally for more than > 30 thirdparty dependencies. So its not only about ensuring that my > packages use the correct thirdparty version, furthermore the packages > themselves have inter-dependencies that must be correctly resolved. > Sorry I missed that part on third party. > So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG, > FindPROJ4, > FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty > dependencies. It would create a maintenance hell :-( > Yep I can perfectly imagine. I know well a project for which we do exactly that. 1) Collect all third party sources for which we want to control precise version (and/or need a patch) 2) Configure, compile and install them all on a private dir 3) Configure and build my project using those installed 3rd party libs. this is the only way we can find to have "clean" multi-linux-distrib' support. How are other people resolving this? > I'm interesting in this as well, but as soon as a 3rd party is using something you use you end-up putting your hand in third party or override system lib (which is not an option for us). -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Fri Mar 23 12:18:45 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Fri, 23 Mar 2018 17:18:45 +0100 Subject: [CMake] adding cmake managed external projects with their config Message-ID: <214251b6-7c58-30c1-4d31-8af87f0ea546@numalliance.com> Hi, I have an experimental Bullet package I would like to use, but I don't manage to override the system CMAKE_MODULE_PATH for bullet to use the new one. I tried using ExternalProject_Add (Bullet?????? SOURCE_DIR "bullet3/build_cmake") but this does not seem the RIGHT way... Overriding CMAKE_MODULE_PATH does not work, since cmake at first uses it's own. Any idea ? From MillerHenry at JohnDeere.com Fri Mar 23 15:41:12 2018 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Fri, 23 Mar 2018 19:41:12 +0000 Subject: [CMake] build times increase 1.5x from cmake 2.8.12 to 3 Message-ID: I have a fairly large project that I'm trying to update from building with cmake 2.8.12 to 3.10.2. When I make the change my build times go up by half on our Jenkins ci build system. The build machines are 32 core and my build time goes from 59m 38s to 1h 28m 33s. When I try this locally the time goes from 80 minutes to 84 minutes (a 6 core machine, but I'm running Debug while the ci system is running RelWithDebInfo so the times cannot be compared). My current effort is targeting 3.10.2, but I've had similar results with 3.2 and 3.9. I compared command line of just one file and it looks like the only significant difference is 2.8.12 was passing -MMD to gcc, while 3.10.2 is using -MD. I'm suspecting that this is the significant difference. Is there a way to get cmake to use -MMD? Or better yet, since our CI machines never do an incremental build is there a way to turn off dependency generation that might speed my build up more? We are using the ninja Generator. Of course I just sampled one of our 17000 build steps to decide the above was the problem. It is entirely possible that I'm off base and something else is the issue. If you have an idea of where I should look instead I'm open to that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Mar 23 16:48:22 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 23 Mar 2018 16:48:22 -0400 Subject: [CMake] build times increase 1.5x from cmake 2.8.12 to 3 In-Reply-To: References: Message-ID: My initial thought is that the differences between -mmd and -md would be pretty minimal. The original discussion on this change ( https://cmake.org/Bug/view.php?id=14914 ) has people agreeing with that as this information is generated when the compiler builds each file. Have you used something like ninja browse / ninja graph ( https://ninja-build.org/manual.html ) to verify the build graph from 2.8.12 to 3.X are the same? On Fri, Mar 23, 2018 at 3:41 PM, Miller Henry wrote: > I have a fairly large project that I?m trying to update from building with > cmake 2.8.12 to 3.10.2. When I make the change my build times go up by half > on our Jenkins ci build system. The build machines are 32 core and my build > time goes from 59m 38s to 1h 28m 33s. When I try this locally the time goes > from 80 minutes to 84 minutes (a 6 core machine, but I?m running Debug while > the ci system is running RelWithDebInfo so the times cannot be compared). > My current effort is targeting 3.10.2, but I?ve had similar results with 3.2 > and 3.9. > > I compared command line of just one file and it looks like the only > significant difference is 2.8.12 was passing -MMD to gcc, while 3.10.2 is > using -MD. I?m suspecting that this is the significant difference. Is there > a way to get cmake to use -MMD? Or better yet, since our CI machines never > do an incremental build is there a way to turn off dependency generation > that might speed my build up more? We are using the ninja Generator. > > Of course I just sampled one of our 17000 build steps to decide the above > was the problem. It is entirely possible that I?m off base and something > else is the issue. If you have an idea of where I should look instead I?m > open to that. > > > > > -- > > 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 > From kbelco at sandia.gov Fri Mar 23 16:54:21 2018 From: kbelco at sandia.gov (Belcourt, Kenneth) Date: Fri, 23 Mar 2018 20:54:21 +0000 Subject: [CMake] Enabling Fortran only builds with Cmake 3.10.2 on Windows Message-ID: Hi, I have a project that builds fine on Mac and Linux by disabling C/C++ and building with only Fortran. PROJECT(Noel LANGUAGES Fortran) When I try to build on Windows, it seems that CMake is looking for variable VCTargetsPath, here?s the error: Setting environment for using Microsoft Visual Studio Shell 13.0 x64 tools. CMake Error at CMakeLists.txt:3 (PROJECT): Failed to run MSBuild command: C:/Program Files (x86)/MSBuild/12.0/bin/MSBuild.exe to get the value of VCTargetsPath: This looks like a Visual C variable which is not installed on this system. Is CMake looking in the registry for this variable or is it MSBuild.exe? I?m not very Windows conversant so I could be completely off base here. Note that I?ve installed Intel Fortran 17.0.4 and have run the ifortvars.bat file for arch intel64. Noel Belcourt From sancelot at numalliance.com Mon Mar 26 02:46:29 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Mon, 26 Mar 2018 08:46:29 +0200 Subject: [CMake] adding cmake managed external projects with their config In-Reply-To: <214251b6-7c58-30c1-4d31-8af87f0ea546@numalliance.com> References: <214251b6-7c58-30c1-4d31-8af87f0ea546@numalliance.com> Message-ID: Le 23/03/2018 ? 17:18, St?phane Ancelot a ?crit?: > Hi, > > I have an experimental Bullet package I would like to use, but I don't > manage to override the system CMAKE_MODULE_PATH for bullet to use the > new one. > > I tried using > > ExternalProject_Add (Bullet?????? SOURCE_DIR "bullet3/build_cmake") > > > but this does not seem the RIGHT way... > > Overriding CMAKE_MODULE_PATH does not work, since cmake at first uses > it's own. > > logically, since I have 2 version of bullet in my system, I should be able to focus on only one requiring the right version in find_package, but that does not seem to work as expected ...or I certainly made something wrong > Any idea ? > > > > From cameron at promon.no Mon Mar 26 04:24:56 2018 From: cameron at promon.no (Cameron Palmer) Date: Mon, 26 Mar 2018 08:24:56 +0000 Subject: [CMake] Cmake Frameworks and Bitcode In-Reply-To: References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: Quite possible I?m misunderstanding something, but? As you said, I really don?t care much at this point about the RPATH. However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn?t change anything as far as I can tell. The target is still linked with -headerpad_max_install_names and the linker still complains. Also, looking at policy 68 and working with the INSTALL_NAME, which is the one thing you do care about, you cannot set the directory to @rpath which seems silly. Most frameworks I?m familiar with have the install name set to @rpath/My.framwork/my. I use add_custom_command to correctly set it, but still seems like this is broken. The library I?ve been testing is iperf, it is relatively straightforward, so it makes a good test case. I?ve added CMake and it is at https://github.com/palmerc/iperf. Cameron. > On 19 Mar 2018, at 12:54, Brad King wrote: > > On 03/12/2018 10:36 AM, Cameron Palmer wrote: >> So after a bit of hacking it seems that Cmake should provide something like: >> >> CMAKE_OSX_BITCODE_ENABLE > > For reference, this refers to a previous post: > > Bitcode and CMake > https://cmake.org/pipermail/cmake/2018-March/067191.html > > with the goal of using `-fembed-bitcode` while avoiding a warning: > > ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) > >> Which would pass -fembed-bitcode to the compiler and linker and remove >> the option in Darwin.cmake for -Wl,-headerpad_max_install_names in >> CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS. > > One may avoid the `-headerpad_max_install_names` option with this: > > https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html > > There is no reason to build with any rpath set for the build tree > when one cannot run the binaries on the macOS host anyway. > > -Brad From james.weir at wesio.co.uk Mon Mar 26 05:19:46 2018 From: james.weir at wesio.co.uk (James Weir) Date: Mon, 26 Mar 2018 10:19:46 +0100 Subject: [CMake] CMAKE_SYSROOT and CMAKE_OSX_SYSROOT Message-ID: I?ve recently been experimenting with using Conan as a package manager for our C++ components, the good news is most things work really well but I?ve come across something which I?m not sure what the behaviour should be with regards to CMake. The problem occurs for me when building for Darwin targets (macOS and iOS), specifically around the behaviour of CMAKE_SYSROOT and CMAKE_OSX_SYSROOT. In short conan cmake builder sets CMAKE_SYSROOT but not CMAKE_OSX_SYSROOT and this causes me problems as I end up with multiple isysroot parameters given to the compiler, typically the host one trumps and so I end up with build errors due to trying to use includes from the macOS platform SDK rather than the appropriate iOS one. I can work around it by setting CMAKE_OSX_SYSROOT explicitly to to the same as CMAKE_SYSROOT and then everything works correctly, but could someone tell me why there are two SYSROOTs in the first place and what the expected behaviour should be? Thanks! From craig.scott at crascit.com Mon Mar 26 06:32:00 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 26 Mar 2018 21:32:00 +1100 Subject: [CMake] CMAKE_SYSROOT and CMAKE_OSX_SYSROOT In-Reply-To: References: Message-ID: On Mon, Mar 26, 2018 at 8:19 PM, James Weir wrote: > I?ve recently been experimenting with using Conan as a package manager for > our C++ components, the good news is most things work really well but I?ve > come across something which I?m not sure what the behaviour should be with > regards to CMake. The problem occurs for me when building for Darwin > targets (macOS and iOS), specifically around the behaviour of CMAKE_SYSROOT > and CMAKE_OSX_SYSROOT. > > In short conan cmake builder sets CMAKE_SYSROOT but not CMAKE_OSX_SYSROOT > and this causes me problems as I end up with multiple isysroot parameters > given to the compiler, typically the host one trumps and so I end up with > build errors due to trying to use includes from the macOS platform SDK > rather than the appropriate iOS one. I can work around it by setting > CMAKE_OSX_SYSROOT explicitly to to the same as CMAKE_SYSROOT and then > everything works correctly, but could someone tell me why there are two > SYSROOTs in the first place and what the expected behaviour should be? > While I can't answer the "why" part, my understanding is that CMAKE_SYSROOT isn't usually set when building for any Apple platform, but you do definitely want CMAKE_OSX_SYSROOT set as it is the one that controls the SDK used, etc. The CMAKE_OSX_SYSROOT can be something as simple as "iphoneos" rather than a full path to the actual SDK location (the need to use a full path to an SDK should be rare, it's usually going to be more flexible to specify just the basic family of SDK you want to use). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 26 09:19:13 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Mar 2018 09:19:13 -0400 Subject: [CMake] Cmake Frameworks and Bitcode In-Reply-To: References: <770C3818-AFE7-47D2-A28E-86CD6E9496A8@promon.no> Message-ID: <27205fe9-602e-4280-19ac-7dbaf5e7becd@kitware.com> On 03/26/2018 04:24 AM, Cameron Palmer wrote: > However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't > change anything as far as I can tell. The target is still linked with > -headerpad_max_install_names and the linker still complains. Oops, I mixed up functionality with other platforms. On platforms that do not have `-headerpad_max_install_names` we generate bogus rpath content in the build tree to pad out enough space to replace it in the installed binary in the install tree. That behavior is turned off by BUILD_WITH_INSTALL_RPATH. On Apple platforms with `-headerpad_max_install_names` the flag is simply hard-coded. CMake would indeed need a new abstraction for `-fembed-bitcode`. Also, CMP0068 means the BUILD_WITH_INSTALL_NAME_DIR should be used instead of BUILD_WITH_INSTALL_RPATH. > Also, looking at policy 68 and working with the INSTALL_NAME, which > is the one thing you do care about, you cannot set the directory to > @rpath which seems silly. Sure we can. CMP0068 is only about the names of the CMake properties that influence the behavior. The INSTALL_NAME_DIR property can be set to "@rpath". -Brad From brad.king at kitware.com Mon Mar 26 09:55:45 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Mar 2018 09:55:45 -0400 Subject: [CMake] target_compile_features no known features for CXX compiler for clang 9.0 In-Reply-To: References: Message-ID: On 03/20/2018 08:52 PM, Rick Mann wrote: > Xcode (Version 9.2 (9C40b)) That works with CMake 3.11.0-rc4 AFAIK. > CMake Error at cmake/AddCeresCXX11RequirementsToTarget.cmake:70 (target_compile_features): > target_compile_features no known features for CXX compiler > > "Clang" > > version 9.0.0.9000039. The compiler id should be AppleClang to work with compiler features, but that is controlled by policy CMP0025: https://cmake.org/cmake/help/v3.11/policy/CMP0025.html As of Ceres 1.14.0 they are not setting that policy to NEW: https://github.com/ceres-solver/ceres-solver/blob/1.14.0/CMakeLists.txt#L32-L40 That is necessary for this code: https://github.com/ceres-solver/ceres-solver/blob/1.14.0/cmake/AddCeresCXX11RequirementsToTarget.cmake#L58-L71 to work, since the target_compile_features command expects behavior as of CMake 3.1 or above. Typically the command would only be used after `cmake_minimum_required(VERSION 3.1)` which would automatically set CMP0025 to NEW. Ceres is trying to support older CMake versions and so would need to set the policy manually. -Brad From Harry.Mallon at codex.online Mon Mar 26 11:57:34 2018 From: Harry.Mallon at codex.online (Harry Mallon) Date: Mon, 26 Mar 2018 15:57:34 +0000 Subject: [CMake] MSVC C features Message-ID: Could MSVC be made to work with target_compile_features for C language features? I assume we would need an MSVC-C.cmake file with definitions. At a glance I imagine something simple would do? * C90 available for all supported MSVC * C99 supported/default from MSVC 18.0 = 2013 (https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/) * C11 not supported There are no compile flags (like MSVC-CXX.cmake) and some of the C99 features have been supported back to MSVC 2005/2008. Would that work or is there a reason this is not implemented? Best, Harry Harry Mallon CODEX | Senior Software Engineer 60 Poland Street | London | England | W1F 7NT E harry.mallon at codex.online | T +44 203 7000 989 From miroslav.kes at gmail.com Mon Mar 26 13:40:22 2018 From: miroslav.kes at gmail.com (=?UTF-8?Q?Miroslav_Ke=c5=a1?=) Date: Mon, 26 Mar 2018 19:40:22 +0200 Subject: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling In-Reply-To: <4FAA990D-C8EF-4FF1-9C71-A94E530A7156@cornell.edu> References: <08587f73-c14e-dda2-dc8a-2ef9b45cd136@gmail.com> <4FAA990D-C8EF-4FF1-9C71-A94E530A7156@cornell.edu> Message-ID: <585d5b5e-a46f-9d43-3fc0-62823fad1aa6@gmail.com> I'm cross-compiling in Windows to another target system (VxWorks) but this is not so important. I thought the idea behind the TO_NATIVE_PATH option was that the internal CMake path representation could be transformed to the system native path so that external programs that rely on the native path convention could be easily used during the build. Either this my assumption is wrong or the CMake implementation is wrong. And the documentation should be more detailed on the exact behavior. Mira On 03/21/2018 09:29 PM, Stephen McDowell wrote: > Disclaimer: I cannot speak to intent, and have never used these before. > > So since you?re cross compiling, when looking at the docs (?https://cmake.org/cmake/help/v3.0/command/file.html?), I?*think*?you can get away with using TO_CMAKE_PATH. ?I do?*not*?know how you actually determine this, but the idea would be > > if (CMAKE_CROSSCOMPILING) > ? if (? host is windows ?) > ? ? ? if (? target is unix ?) > ? ? ? ? ? use TO_CMAKE_PATH ? > ? ? ? else() > ? ? ? ? ? use TO_NATIVE_PATH ? > ? ? ? endif() > ? else() # ? host is unix ? > ? ? if (? target is unix ?) > ? ? ? ? use TO_CMAKE_PATH or TO_NATIVE_PATH ? > ? ? else() # ? target is windows > ? ? ? ? PROBLEM ? > ? ? endif() > endif() > > That is, I think if you are compiling?*on*?Windows?*for*?Unix, you can cheat and use TO_CMAKE_PATH to get unix style paths. ?But if you are compiling?*on*?unix?*for*?Windows, I don?t know how you get it to be Windows paths. > > But if this does solve Windows -> Unix, you could maybe just message(FATAL_ERROR ?) saying that cross compiling for Windows from Unix is not supported. ?You could also take a look at the implementation of TO_NATIVE_PATH and just snag the Windows code and make your own function that converts it, maybe calling it to_windows_path() or something? > > I hope that is helpful, but I really don?t know if anything in the above is possible :/ > > > From oliver at revl.com Mon Mar 26 21:06:23 2018 From: oliver at revl.com (Oliver Dain) Date: Tue, 27 Mar 2018 01:06:23 +0000 Subject: [CMake] find_library fails when cross compiling Message-ID: Hi, I have some find_library lines like the following: find_library(protobuf_protobuf protobuf PATHS /Users/oliverdain/Documents/code/revl/.install/${ARCH}/${VARIANT}/protobuf/3.4.1.r1/lib NO_DEFAULT_PATH ) target_link_libraries(ml_editing PUBLIC ${protobuf_protobuf}) These work find when $ARCH and $VARIANT are set to OSX and either Debug or Release (my target system). However, If I run cmake -H. -B/Users/oliverdain/Documents/code/revl/cpp/build/build/IPHONE/Release -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DIOS_PLATFORM=OS -DCMAKE_BUILD_TYPE=Release -DARCH=IPHONE -DVARIANT=Release the libraries are reported not found (the standard "CMake Error: The following variables are used in this project, but they are set to NOTFOUND." error) even though the libraries are in the specified location. For example, it says it can't find the protobuf libs but an ls yields: $ ls /Users/oliverdain/Documents/code/revl/.install/IPHONE/Release/protobuf/3.4.1.r1/lib cmake libprotobuf-lite.a libprotobuf.a pkgconfig Note that if I change the NO_DEFAULT_PATH specification in the find_library line to NO_CMAKE_FIND_ROOT_PATH everything works as expected and the libs are found and linked (and I know its the right libs because things also run). Is this a bug or is there something I don't understand about NO_DEFAULT_PATH? Thanks, Oliver PS: I know the hard coded full path names are odd - the CMakeLists.txt files are actually generated -- it's a long story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Mon Mar 26 21:45:55 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 27 Mar 2018 01:45:55 +0000 Subject: [CMake] Listing all the include directories Message-ID: Hi, I have many libraries and packages that are being linked using target_link_libraries(...) where CMake takes care of the include directories. There are cases where I get compile errors because I don't know the exact include directories. I thought perhaps I could get the include directories of my target by doing the following: get_target_property(INCLUDE_DIRS MyExeThatLinksToManyLibs INCLUDE_DIRECTORIES) message(STATUS ${INCLUDE_DIRS}) # hoped that this would print all the include directories Unfortunately, that did not work as expected. It was missing directories that I know are added to the include directories of the target (because the compiler is able to find the headers properly). Apart from sifting through the compile commands, is there a nice way to debug the include directories of a target? Thank you, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Tue Mar 27 08:19:56 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Tue, 27 Mar 2018 21:19:56 +0900 Subject: [CMake] looking for 2 features to help pkg-config pc files Message-ID: <5ABA36EC.1000007@hiroshima-u.ac.jp> Hi all, I'm looking for 2 features to generate pkg-config pc files. I already wrote something, but some experts advised that there would be many people trying to do such, and there might be existing solution. If such functions are already included in cmake's official modules, please let me know. Of course, combination of existing functions would be OK. function 1) ----------- ...is trying to find an available pkg-config module name from a list of several candidates. the typical usecase would be a search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? libjpeg9? libjpeg62? ...). getting a name of module is important to write "Require" variable of pc file. there is already pkg_search_module() searching an available module from a list, but it does not return the name of found module. thus it cannot help to write "Require" variable. what I wrote is something like this. # # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) # # there is pkg_search_module(), but it does not clarify # which module was found. # # this function does not set xxx_CFLAGS xxx_LIBS etc. # # use like: # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") # function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) set(_PKG_FOUND FALSE) foreach(_pkg IN LISTS pkg_list) pkg_check_modules(_PKG "${_pkg}") if (_PKG_FOUND) set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) return() endif() endforeach(_pkg) endfunction(PKG_SEARCH_AVAILABLE_MODULE) function 2) ----------- ...makes something like LDFLAGS + LIBS from the pathnames of libraries. some library finders of cmake do not return "-L/xxx -lyyy" values but returns "/xxx/libyyy.so". pkg-config has some difficulties to hold such raw pathnames of the libraries (e.g. pkg-config use "Libs" variable for both of static and shared linking, thus having "libxxx.a" or "libxxx.so" explicitly is not good), so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". what I wrote is something like this: # # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) # function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) foreach(_libpath IN LISTS _libpaths) string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") string(REGEX REPLACE "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib "${_lib}") string(REGEX REPLACE "^lib" "" _lib "${_lib}") set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") endforeach(_libpath) set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) endfunction(MAKE_LDFLAGS_FROM_LIBPATH) Regards, mpsuzuki From craig.scott at crascit.com Tue Mar 27 09:04:39 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 28 Mar 2018 00:04:39 +1100 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <5ABA36EC.1000007@hiroshima-u.ac.jp> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: You most likely want to use the FindPkgConfig module and also use the IMPORTED_TARGET option with the commands provided therein. On Tue, Mar 27, 2018 at 11:19 PM, suzuki toshiya wrote: > Hi all, > > I'm looking for 2 features to generate pkg-config pc files. > I already wrote something, but some experts advised that there > would be many people trying to do such, and there might be existing > solution. If such functions are already included in cmake's > official modules, please let me know. Of course, combination > of existing functions would be OK. > > function 1) > ----------- > > ...is trying to find an available pkg-config module name from a > list of several candidates. the typical usecase would be a > search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? > libjpeg9? libjpeg62? ...). getting a name of module is important > to write "Require" variable of pc file. > > there is already pkg_search_module() searching an available module > from a list, but it does not return the name of found module. > thus it cannot help to write "Require" variable. > > what I wrote is something like this. > > # > # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) > # > # there is pkg_search_module(), but it does not clarify > # which module was found. > # > # this function does not set xxx_CFLAGS xxx_LIBS etc. > # > # use like: > # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG > "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") > # > function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) > set(_PKG_FOUND FALSE) > foreach(_pkg IN LISTS pkg_list) > pkg_check_modules(_PKG "${_pkg}") > if (_PKG_FOUND) > set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) > set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) > return() > endif() > endforeach(_pkg) > endfunction(PKG_SEARCH_AVAILABLE_MODULE) > > function 2) > ----------- > ...makes something like LDFLAGS + LIBS from the pathnames of libraries. > some library finders of cmake do not return "-L/xxx -lyyy" values > but returns "/xxx/libyyy.so". pkg-config has some difficulties > to hold such raw pathnames of the libraries (e.g. pkg-config > use "Libs" variable for both of static and shared linking, > thus having "libxxx.a" or "libxxx.so" explicitly is not good), > so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". > > what I wrote is something like this: > > # > # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) > # > function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) > foreach(_libpath IN LISTS _libpaths) > string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") > > string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") > string(REGEX REPLACE > "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" > _lib > "${_lib}") > string(REGEX REPLACE "^lib" "" _lib "${_lib}") > > set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} > ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") > endforeach(_libpath) > set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) > endfunction(MAKE_LDFLAGS_FROM_LIBPATH) > > Regards, > mpsuzuki > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Mar 27 10:47:08 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 27 Mar 2018 10:47:08 -0400 Subject: [CMake] Listing all the include directories In-Reply-To: References: Message-ID: In general your options are to look at the command line or use cmake-server mode to query the code model. The full set of include directories is not known while configuring due to generator expressions expanding after the configure step. On Mon, Mar 26, 2018 at 9:45 PM, Saad Khattak wrote: > Hi, > > I have many libraries and packages that are being linked using > target_link_libraries(...) where CMake takes care of the include > directories. There are cases where I get compile errors because I don't know > the exact include directories. > > I thought perhaps I could get the include directories of my target by doing > the following: > > get_target_property(INCLUDE_DIRS MyExeThatLinksToManyLibs > INCLUDE_DIRECTORIES) > message(STATUS ${INCLUDE_DIRS}) # hoped that this would print all the > include directories > > Unfortunately, that did not work as expected. It was missing directories > that I know are added to the include directories of the target (because the > compiler is able to find the headers properly). > > Apart from sifting through the compile commands, is there a nice way to > debug the include directories of a target? > > Thank you, > Saad > > -- > > 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 > From mpsuzuki at hiroshima-u.ac.jp Tue Mar 27 12:10:32 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Wed, 28 Mar 2018 01:10:32 +0900 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <7fffaee73cf840789c3bfc457870e0e6@OS2PR01MB1147.jpnprd01.prod.outlook.com> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> <7fffaee73cf840789c3bfc457870e0e6@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <5ABA6CF8.3060507@hiroshima-u.ac.jp> Dear Craig, Thank you for prompt reply. But all 3 functions; pkg_get_variable(), pkg_check_modules(), pkg_search_module() are different from my purpose. in my impression, these functions are designed to retrieve the infos from/via pkg-config, not to generate the infos to be written in pkg- config's pc files. for the function 1 (lookup an available module from a list), pkg_check_modules() and pkg_search_module() are candidate, but they are not the straight solutions. taking a case that trying to find available module from libjpeg, libjpeg8, libjpeg8-turbo, libjpeg9, libjpeg62, how pkg_check_modules() or pkg_search_module() could be used? it would be something like... pkg_check_modules(_pc libjpeg libjpeg8 libjpeg8-turbo libjpeg9 libjpeg62) foreach(mod IN LISTS "libjpeg;libjpeg8;libjpeg8-turbo;libjpeg9;libjpeg62") if (NOT ("${_pc_${mod}_VERSION}" STREQUAL "")) set(FOUND_MOD "${mod}") endif() endforeach(mod) message("${FOUND_MOD} is first available module") I think it's slightly troublesome, because I have to write single list at 2 places, in different syntax. -- Also, yet I'm not sure how IMPORTED_TARGET could be used to make "-L/xxx -lyyy" from "/xxx/libyyy.so". According to https://cmake.org/cmake/help/latest/command/target_link_libraries.html , the contents of the imported target are the full pathnames of the libraries, or, the plain library name ("bar" of "libbar.so"), or other linker flag. The function I'm looking for is a conversion *from* the full pathname *to* linker flag + plain library name. I cannot find if imported target has a conversion feature from one to another - am I overlooking something important? Regards, mpsuzuki Craig Scott wrote: > You most likely want to use the FindPkgConfig module and also use the IMPORTED_TARGET option with the commands provided therein. > > On Tue, Mar 27, 2018 at 11:19 PM, suzuki toshiya > wrote: > Hi all, > > I'm looking for 2 features to generate pkg-config pc files. > I already wrote something, but some experts advised that there > would be many people trying to do such, and there might be existing > solution. If such functions are already included in cmake's > official modules, please let me know. Of course, combination > of existing functions would be OK. > > function 1) > ----------- > > ...is trying to find an available pkg-config module name from a > list of several candidates. the typical usecase would be a > search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? > libjpeg9? libjpeg62? ...). getting a name of module is important > to write "Require" variable of pc file. > > there is already pkg_search_module() searching an available module > from a list, but it does not return the name of found module. > thus it cannot help to write "Require" variable. > > what I wrote is something like this. > > # > # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) > # > # there is pkg_search_module(), but it does not clarify > # which module was found. > # > # this function does not set xxx_CFLAGS xxx_LIBS etc. > # > # use like: > # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG > "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") > # > function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) > set(_PKG_FOUND FALSE) > foreach(_pkg IN LISTS pkg_list) > pkg_check_modules(_PKG "${_pkg}") > if (_PKG_FOUND) > set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) > set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) > return() > endif() > endforeach(_pkg) > endfunction(PKG_SEARCH_AVAILABLE_MODULE) > > function 2) > ----------- > ...makes something like LDFLAGS + LIBS from the pathnames of libraries. > some library finders of cmake do not return "-L/xxx -lyyy" values > but returns "/xxx/libyyy.so". pkg-config has some difficulties > to hold such raw pathnames of the libraries (e.g. pkg-config > use "Libs" variable for both of static and shared linking, > thus having "libxxx.a" or "libxxx.so" explicitly is not good), > so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". > > what I wrote is something like this: > > # > # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) > # > function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) > foreach(_libpath IN LISTS _libpaths) > string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") > > string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") > string(REGEX REPLACE > "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib > "${_lib}") > string(REGEX REPLACE "^lib" "" _lib "${_lib}") > > set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} > ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") > endforeach(_libpath) > set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) > endfunction(MAKE_LDFLAGS_FROM_LIBPATH) > > Regards, > mpsuzuki > > -- > > 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 > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > From realnc at gmail.com Tue Mar 27 13:05:58 2018 From: realnc at gmail.com (Nikos Chantziaras) Date: Tue, 27 Mar 2018 20:05:58 +0300 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <5ABA6CF8.3060507@hiroshima-u.ac.jp> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> <7fffaee73cf840789c3bfc457870e0e6@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5ABA6CF8.3060507@hiroshima-u.ac.jp> Message-ID: Is there a reason why you can't generate your .pc file from a .pc.in file using the configure_file() function? As in: configure_file( ${PROJECT_SOURCE_DIR}/mylibrary.pc.in ${PROJECT_BINARY_DIR}/mylibrary.pc @ONLY ) Your mylibrary.pc.in file would look something like this: prefix="@CMAKE_INSTALL_PREFIX@" exec_prefix="${prefix}" libdir="${prefix}/@CMAKE_INSTALL_LIBDIR@" includedir="${prefix}/include/mylibrary" Name: MyLibrary Description: A library for xyzzying frobnixes URL: https://github.com/me/mylibrary Version: 0.0.0 Requires: @PKGCONF_REQ_PUB@ Requires.private: @PKGCONF_REQ_PRIV@ Cflags: -I"${includedir}" Libs: -L"${libdir}" -lmylibrary Libs.private: -L"${libdir}" -lmylibrary @PKGCONF_LIBS_PRIV@ You then set the PKGCONF_* variables in your cmake file. This is what I use in a project of mine. You can use it as an example: https://github.com/realnc/SDL_audiolib/blob/master/CMakeLists.txt On 27/03/18 19:10, suzuki toshiya wrote: > Dear Craig, > > Thank you for prompt reply. But all 3 functions; pkg_get_variable(), > pkg_check_modules(), pkg_search_module() are different from my purpose. > > in my impression, these functions are designed to retrieve the infos > from/via pkg-config, not to generate the infos to be written in pkg- > config's pc files. > > for the function 1 (lookup an available module from a list), > pkg_check_modules() and pkg_search_module() are candidate, but > they are not the straight solutions. > > taking a case that trying to find available module from libjpeg, > libjpeg8, libjpeg8-turbo, libjpeg9, libjpeg62, how pkg_check_modules() > or pkg_search_module() could be used? it would be something like... > > pkg_check_modules(_pc libjpeg libjpeg8 libjpeg8-turbo libjpeg9 libjpeg62) > foreach(mod IN LISTS "libjpeg;libjpeg8;libjpeg8-turbo;libjpeg9;libjpeg62") > if (NOT ("${_pc_${mod}_VERSION}" STREQUAL "")) > set(FOUND_MOD "${mod}") > endif() > endforeach(mod) > message("${FOUND_MOD} is first available module") > > I think it's slightly troublesome, because I have to write single > list at 2 places, in different syntax. > > -- > > Also, yet I'm not sure how IMPORTED_TARGET could be used to make > "-L/xxx -lyyy" from "/xxx/libyyy.so". According to > https://cmake.org/cmake/help/latest/command/target_link_libraries.html > , the contents of the imported target are the full pathnames of > the libraries, or, the plain library name ("bar" of "libbar.so"), > or other linker flag. The function I'm looking for is a conversion > *from* the full pathname *to* linker flag + plain library name. > I cannot find if imported target has a conversion feature from one > to another - am I overlooking something important? > > Regards, > mpsuzuki > > Craig Scott wrote: >> You most likely want to use the FindPkgConfig module and also use the IMPORTED_TARGET option with the commands provided therein. >> >> On Tue, Mar 27, 2018 at 11:19 PM, suzuki toshiya > wrote: >> Hi all, >> >> I'm looking for 2 features to generate pkg-config pc files. >> I already wrote something, but some experts advised that there >> would be many people trying to do such, and there might be existing >> solution. If such functions are already included in cmake's >> official modules, please let me know. Of course, combination >> of existing functions would be OK. >> >> function 1) >> ----------- >> >> ...is trying to find an available pkg-config module name from a >> list of several candidates. the typical usecase would be a >> search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? >> libjpeg9? libjpeg62? ...). getting a name of module is important >> to write "Require" variable of pc file. >> >> there is already pkg_search_module() searching an available module >> from a list, but it does not return the name of found module. >> thus it cannot help to write "Require" variable. >> >> what I wrote is something like this. >> >> # >> # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) >> # >> # there is pkg_search_module(), but it does not clarify >> # which module was found. >> # >> # this function does not set xxx_CFLAGS xxx_LIBS etc. >> # >> # use like: >> # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG >> "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") >> # >> function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) >> set(_PKG_FOUND FALSE) >> foreach(_pkg IN LISTS pkg_list) >> pkg_check_modules(_PKG "${_pkg}") >> if (_PKG_FOUND) >> set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) >> set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) >> return() >> endif() >> endforeach(_pkg) >> endfunction(PKG_SEARCH_AVAILABLE_MODULE) >> >> function 2) >> ----------- >> ...makes something like LDFLAGS + LIBS from the pathnames of libraries. >> some library finders of cmake do not return "-L/xxx -lyyy" values >> but returns "/xxx/libyyy.so". pkg-config has some difficulties >> to hold such raw pathnames of the libraries (e.g. pkg-config >> use "Libs" variable for both of static and shared linking, >> thus having "libxxx.a" or "libxxx.so" explicitly is not good), >> so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". >> >> what I wrote is something like this: >> >> # >> # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) >> # >> function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) >> foreach(_libpath IN LISTS _libpaths) >> string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") >> >> string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") >> string(REGEX REPLACE >> "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib >> "${_lib}") >> string(REGEX REPLACE "^lib" "" _lib "${_lib}") >> >> set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} >> ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") >> endforeach(_libpath) >> set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) >> endfunction(MAKE_LDFLAGS_FROM_LIBPATH) >> >> Regards, >> mpsuzuki >> >> -- >> >> 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 >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > From irwin at beluga.phys.uvic.ca Tue Mar 27 13:36:51 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 27 Mar 2018 10:36:51 -0700 (PDT) Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <5ABA36EC.1000007@hiroshima-u.ac.jp> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: On 2018-03-27 21:19+0900 suzuki toshiya wrote: > Hi all, > > I'm looking for 2 features to generate pkg-config pc files. Hi Suzuki: CMake has its own native way of generating package information describing software (see, ). So it would be worthwhile in its own right for you to generate a native CMake package for your software to benefit those of your users who want to use find_package in Config mode to obtain all the information they need about your software. In fact, it has been argued (see ) that native CMake packages are so useful that it is worthwhile generating those for external projects that don't produce them for themselves. Now moving to your question, once a native CMake package describing software has been implemented, then it should be possible, in principle, to translate the information in that native package into pkg-config form (for the benefit of those who prefer pkg-config to find_package in Config mode to obtain information about a software package). So this is an indirect way of fulfilling your need to generate information about your software in pkg-config form, but the very large side benefit is you also provide that information in native CMake package form. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From realnc at gmail.com Tue Mar 27 14:25:51 2018 From: realnc at gmail.com (Nikos Chantziaras) Date: Tue, 27 Mar 2018 21:25:51 +0300 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: Note that one downside to that is that people not using CMake cannot make use of that. They still need a pkgconfig file. So in a sense, pkgconfig is the common denominator everybody can use, regardless of build system. On 27/03/18 20:36, Alan W. Irwin wrote: > On 2018-03-27 21:19+0900 suzuki toshiya wrote: > >> Hi all, >> >> I'm looking for 2 features to generate pkg-config pc files. > > Hi Suzuki: > > CMake has its own native way of generating package information > describing software (see, > ). > So it would be worthwhile in its own right for you to generate a > native CMake package for your software to benefit those of your users > who want to use find_package in Config mode to obtain all the > information they need about your software.? In fact, it has been > argued (see > ) > that native CMake packages are so useful that it is worthwhile > generating those for external projects that don't produce them for > themselves. > > Now moving to your question, once a native CMake package describing > software has been implemented, then it should be possible, in > principle, to translate the information in that native package into > pkg-config form (for the benefit of those who prefer pkg-config to > find_package in Config mode to obtain information about a software > package).? So this is an indirect way of fulfilling your need to > generate information about your software in pkg-config form, but the > very large side benefit is you also provide that information in native > CMake package form. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From eike at sf-mail.de Tue Mar 27 14:35:31 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 27 Mar 2018 20:35:31 +0200 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: <2204529.GSuhrozkxL@daneel.sf-tec.de> Am Dienstag, 27. M?rz 2018, 21:25:51 schrieb Nikos Chantziaras: > Note that one downside to that is that people not using CMake cannot > make use of that. They still need a pkgconfig file. So in a sense, > pkgconfig is the common denominator everybody can use, regardless of > build system. What happened with that autoconf macro that was able to read in .cmake files? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From realnc at gmail.com Tue Mar 27 14:46:43 2018 From: realnc at gmail.com (Nikos Chantziaras) Date: Tue, 27 Mar 2018 21:46:43 +0300 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <2204529.GSuhrozkxL@daneel.sf-tec.de> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> <2204529.GSuhrozkxL@daneel.sf-tec.de> Message-ID: On 27/03/18 21:35, Rolf Eike Beer wrote: > Am Dienstag, 27. M?rz 2018, 21:25:51 schrieb Nikos Chantziaras: >> Note that one downside to that is that people not using CMake cannot >> make use of that. They still need a pkgconfig file. So in a sense, >> pkgconfig is the common denominator everybody can use, regardless of >> build system. > > What happened with that autoconf macro that was able to read in .cmake files? I don't know. But there's other build systems out there too. Like Meson, qmake, qbs... pkgconfig does seem like the sane thing to offer. Basically, whenever I see a build system trying to invent its own package configuration system, xkcb 927 pops into my mind :-P From irwin at beluga.phys.uvic.ca Tue Mar 27 16:53:38 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 27 Mar 2018 13:53:38 -0700 (PDT) Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: On 2018-03-27 21:25+0300 Nikos Chantziaras wrote: > Note that one downside to that is that people not using CMake cannot make use > of that. They still need a pkgconfig file. So in a sense, pkgconfig is the > common denominator everybody can use, regardless of build system. It is not an either-or proposition. Both kinds of packages are useful. The pkg-config package is useful for the (lowest) common-denominator reason you state, but for those already using CMake, a native CMake package is considerably more powerful (e.g., the ability to use generator expressions based on packages imported from a native CMake package). For these reasons in the PLplot case I generate both pkg-config and native packages. The current implementation uses independent logic for each kind of package, but to absolutely guarantee consistent information for the two kinds of packages, it would be desireable to move to an implementation that uses generator expressions to extract the required compiler and linker data from a generated native package and configure the pkg-config result directly from those data. So if somebody here has already tried that approach or the alternative approach of converting pkg-config packages to native packages, I would like to hear about it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From saadrustam at gmail.com Tue Mar 27 22:32:51 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Wed, 28 Mar 2018 02:32:51 +0000 Subject: [CMake] Listing all the include directories In-Reply-To: References: Message-ID: Thanks Robert. Too bad that this something I cannot inspect. A list of include directories would be useful even with unexpanded generator expressions. CMake-server mode sounds like an interesting option. On Tue, Mar 27, 2018 at 10:47 AM Robert Maynard wrote: > In general your options are to look at the command line or use > cmake-server mode to query the code model. The full set of include > directories is not known while configuring due to generator > expressions expanding after the configure step. > > On Mon, Mar 26, 2018 at 9:45 PM, Saad Khattak > wrote: > > Hi, > > > > I have many libraries and packages that are being linked using > > target_link_libraries(...) where CMake takes care of the include > > directories. There are cases where I get compile errors because I don't > know > > the exact include directories. > > > > I thought perhaps I could get the include directories of my target by > doing > > the following: > > > > get_target_property(INCLUDE_DIRS MyExeThatLinksToManyLibs > > INCLUDE_DIRECTORIES) > > message(STATUS ${INCLUDE_DIRS}) # hoped that this would print all the > > include directories > > > > Unfortunately, that did not work as expected. It was missing directories > > that I know are added to the include directories of the target (because > the > > compiler is able to find the headers properly). > > > > Apart from sifting through the compile commands, is there a nice way to > > debug the include directories of a target? > > > > Thank you, > > Saad > > > > -- > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Tue Mar 27 22:34:27 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Wed, 28 Mar 2018 11:34:27 +0900 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: References: <5ABA36EC.1000007@hiroshima-u.ac.jp> <7fffaee73cf840789c3bfc457870e0e6@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5ABA6CF8.3060507@hiroshima-u.ac.jp> Message-ID: <5ABAFF33.6070602@hiroshima-u.ac.jp> Dear Nikos, Thank you for concrete suggestion! Nikos Chantziaras wrote: > Is there a reason why you can't generate your .pc file from a .pc.in > file using the configure_file() function? Yes, that's what I'm doing now :-) https://github.com/mpsuzuki/poppler/compare/5e7aef9d...52ec0ec8#diff-af3b638bc2a3e6c650974192a53c7291 > Requires: @PKGCONF_REQ_PUB@ > Requires.private: @PKGCONF_REQ_PRIV@ > Libs.private: -L"${libdir}" -lmylibrary @PKGCONF_LIBS_PRIV@ Here here. The functions I'm looking for is the helper functions to construct @PKGCONF_REQ_PUB@, @PKGCONF_REQ_PRIV@, and @PKGCONF_LIBS_PRIV at . > You then set the PKGCONF_* variables in your cmake file. This is what I > use in a project of mine. You can use it as an example: > > https://github.com/realnc/SDL_audiolib/blob/master/CMakeLists.txt Also thanks for concrete example. It seems that you have already spot the appropriate pkg-config module name to be written in pc file (so you could hardcode the name of the module). My problem is that sometimes the appropriate pkg-config module name is unclear, because some package finders in cmake do not invoke pkg-config at all, or, even if pkg-config is invoked, some package finders do not return the names of found modules. -- Reading other (kind) suggestions to me, it seems that the majority of cmake users think "retrieving the info from pkg-config is still practical in some cases, but providing the info to pkg-config is not practical anymore". that's ok, it answers my question "why I cannot find these functions?", the answer was simple "because few people wanted such". Sincerely I thank to everybody answered to my question. Regards, mpsuzuki > On 27/03/18 19:10, suzuki toshiya wrote: >> Dear Craig, >> >> Thank you for prompt reply. But all 3 functions; pkg_get_variable(), >> pkg_check_modules(), pkg_search_module() are different from my purpose. >> >> in my impression, these functions are designed to retrieve the infos >> from/via pkg-config, not to generate the infos to be written in pkg- >> config's pc files. >> >> for the function 1 (lookup an available module from a list), >> pkg_check_modules() and pkg_search_module() are candidate, but >> they are not the straight solutions. >> >> taking a case that trying to find available module from libjpeg, >> libjpeg8, libjpeg8-turbo, libjpeg9, libjpeg62, how pkg_check_modules() >> or pkg_search_module() could be used? it would be something like... >> >> pkg_check_modules(_pc libjpeg libjpeg8 libjpeg8-turbo libjpeg9 libjpeg62) >> foreach(mod IN LISTS "libjpeg;libjpeg8;libjpeg8-turbo;libjpeg9;libjpeg62") >> if (NOT ("${_pc_${mod}_VERSION}" STREQUAL "")) >> set(FOUND_MOD "${mod}") >> endif() >> endforeach(mod) >> message("${FOUND_MOD} is first available module") >> >> I think it's slightly troublesome, because I have to write single >> list at 2 places, in different syntax. >> >> -- >> >> Also, yet I'm not sure how IMPORTED_TARGET could be used to make >> "-L/xxx -lyyy" from "/xxx/libyyy.so". According to >> https://cmake.org/cmake/help/latest/command/target_link_libraries.html >> , the contents of the imported target are the full pathnames of >> the libraries, or, the plain library name ("bar" of "libbar.so"), >> or other linker flag. The function I'm looking for is a conversion >> *from* the full pathname *to* linker flag + plain library name. >> I cannot find if imported target has a conversion feature from one >> to another - am I overlooking something important? >> >> Regards, >> mpsuzuki >> >> Craig Scott wrote: >>> You most likely want to use the FindPkgConfig module and also use the IMPORTED_TARGET option with the commands provided therein. >>> >>> On Tue, Mar 27, 2018 at 11:19 PM, suzuki toshiya > wrote: >>> Hi all, >>> >>> I'm looking for 2 features to generate pkg-config pc files. >>> I already wrote something, but some experts advised that there >>> would be many people trying to do such, and there might be existing >>> solution. If such functions are already included in cmake's >>> official modules, please let me know. Of course, combination >>> of existing functions would be OK. >>> >>> function 1) >>> ----------- >>> >>> ...is trying to find an available pkg-config module name from a >>> list of several candidates. the typical usecase would be a >>> search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? >>> libjpeg9? libjpeg62? ...). getting a name of module is important >>> to write "Require" variable of pc file. >>> >>> there is already pkg_search_module() searching an available module >>> from a list, but it does not return the name of found module. >>> thus it cannot help to write "Require" variable. >>> >>> what I wrote is something like this. >>> >>> # >>> # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) >>> # >>> # there is pkg_search_module(), but it does not clarify >>> # which module was found. >>> # >>> # this function does not set xxx_CFLAGS xxx_LIBS etc. >>> # >>> # use like: >>> # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG >>> "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") >>> # >>> function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) >>> set(_PKG_FOUND FALSE) >>> foreach(_pkg IN LISTS pkg_list) >>> pkg_check_modules(_PKG "${_pkg}") >>> if (_PKG_FOUND) >>> set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) >>> set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) >>> return() >>> endif() >>> endforeach(_pkg) >>> endfunction(PKG_SEARCH_AVAILABLE_MODULE) >>> >>> function 2) >>> ----------- >>> ...makes something like LDFLAGS + LIBS from the pathnames of libraries. >>> some library finders of cmake do not return "-L/xxx -lyyy" values >>> but returns "/xxx/libyyy.so". pkg-config has some difficulties >>> to hold such raw pathnames of the libraries (e.g. pkg-config >>> use "Libs" variable for both of static and shared linking, >>> thus having "libxxx.a" or "libxxx.so" explicitly is not good), >>> so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". >>> >>> what I wrote is something like this: >>> >>> # >>> # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) >>> # >>> function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) >>> foreach(_libpath IN LISTS _libpaths) >>> string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") >>> >>> string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") >>> string(REGEX REPLACE >>> "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib >>> "${_lib}") >>> string(REGEX REPLACE "^lib" "" _lib "${_lib}") >>> >>> set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} >>> ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") >>> endforeach(_libpath) >>> set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) >>> endfunction(MAKE_LDFLAGS_FROM_LIBPATH) >>> >>> Regards, >>> mpsuzuki >>> >>> -- >>> >>> 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 >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> > > From bsferrazza at avnera.com Wed Mar 28 13:45:46 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Wed, 28 Mar 2018 10:45:46 -0700 Subject: [CMake] cmake build issue with symlinks and dependencies Message-ID: I'm trying to build libvnc, and I have run into this when building other source code as well. For some reason cmake errors out when checking the dependency of a symlinked file, after executing 'cmake --build .'. I'm not sure I'm even describing that properly. It's best understood by looking at the below. This is the relevant section of the build.make file. libvncclient.so.0.9.12: CMakeFiles/vncclient.dir/link.txt @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold --progress-dir=/home/bsferrazza/lfs/sources/libvncserver/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_10) "Linking C shared library libvncclient.so" $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/vncclient.dir/link.txt --verbose=$(VERBOSE) $(CMAKE_COMMAND) -E cmake_symlink_library libvncclient.so.0.9.12 libvncclient.so.1 libvncclient.so libvncclient.so.1: libvncclient.so.0.9.12 @$(CMAKE_COMMAND) -E touch_nocreate libvncclient.so.1 libvncclient.so: libvncclient.so.0.9.12 @$(CMAKE_COMMAND) -E touch_nocreate libvncclient.so And here's the terminal output. [ 1%] Linking C shared library libvncclient.so /home/tools/bin/cmake -E cmake_link_script CMakeFiles/vncclient.dir/link.txt --verbose=1 /home/tools/bin/cc -fPIC -shared -Wl,-soname,libvncclient.so.1 -o libvncclient.so.0.9.12 CMakeFiles/vncclient.dir/libvncclient/cursor.c.o CMakeFiles/vncclient.dir/libvncclient/listen.c.o CMakeFiles/vncclient.dir/libvncclient/rfbproto.c.o CMakeFiles/vncclient.dir/libvncclient/sockets.c.o CMakeFiles/vncclient.dir/libvncclient/vncviewer.c.o CMakeFiles/vncclient.dir/common/minilzo.c.o CMakeFiles/vncclient.dir/common/turbojpeg.c.o CMakeFiles/vncclient.dir/libvncclient/tls_gnutls.c.o CMakeFiles/vncclient.dir/libvncclient/sasl.c.o -lpthread /home/tools/lib/libgcrypt.so /home/tools/lib/libsasl2.so /home/tools/lib/libz.so /home/tools/lib/libjpeg.so /home/tools/lib/libgnutls.so /home/tools/lib/libssl.so /home/tools/lib/libcrypto.so /home/tools/bin/cmake -E cmake_symlink_library libvncclient.so.0.9.12 libvncclient.so.1 libvncclient.so make[2]: *** [CMakeFiles/vncclient.dir/build.make:317: libvncclient.so] Error 1 make[2]: *** Deleting file 'libvncclient.so' make[2]: Leaving directory '/nfs/home/bsferrazza/lfs/ sources/libvncserver/build' make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/vncclient.dir/all] Error 2 make[1]: Leaving directory '/nfs/home/bsferrazza/lfs/ sources/libvncserver/build' make: *** [Makefile:141: all] Error 2 You can see it run the ' cmake -E cmake_symlink_library libvncclient.so.0.9.12' command and yet it errors out on libvncclient.so. Oddly, if I then run that same command in the shell, and re-run 'cmake --build .' it continues just fine. So why was that command not properly executed within the cmake file? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Mar 28 14:14:53 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 28 Mar 2018 14:14:53 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.11.0 available for download Message-ID: I am proud to announce that CMake 3.11.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.11 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.11/release/3.11.html Some of the more significant changes in CMake 3.11 are: * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CMake 3.11 Release Notes ************************ Changes made since CMake 3.10 include the following. New Features ============ Platforms --------- * TI C/C++ compilers are now supported by the "Ninja" generator. Generators ---------- * The "CodeBlocks" extra generator learned to check a "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler identification value to place in the project file. * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools along with the compiler for the "Fortran" language ("C", "CXX", and "CUDA" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS", "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See generator expression documentation for caveats. * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" "generator expression" in target-wide "COMPILE_DEFINITIONS" and "INCLUDE_DIRECTORIES". It previously supported only "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression documentation for caveats. Commands -------- * "add_library()" and "add_executable()" commands can now be called without any sources and will not complain as long as sources are added later via the "target_sources()" command. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * The "target_compile_definitions()" command learned to set the "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. * The "target_compile_features()" command learned to set the "INTERFACE_COMPILE_FEATURES" property on Imported Targets. * The "target_compile_options()" command learned to set the "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. * The "target_include_directories()" command learned to set the "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. * The "target_sources()" command learned to set the "INTERFACE_SOURCES" property on Imported Targets. * The "target_link_libraries()" command learned to set the "INTERFACE_LINK_LIBRARIES" property on Imported Targets. Variables --------- * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the selected instance of the generator's corresponding native tools if multiple are available. This is used by the "Visual Studio 15 2017" generator to hold the selected instance of Visual Studio persistently. * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added to enable setting of default permissions for directories created implicitly during installation of files by "install()" and "file(INSTALL)", e.g. during "make install". * A "CMAKE_JOB_POOLS" variable was added specify a value to use for the "JOB_POOLS" property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator. * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to specify use of a ".netrc" file by the "file(DOWNLOAD)" and "file(UPLOAD)" commands and the "ExternalProject" module. * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to initialize the "CUDA_SEPARABLE_COMPILATION" target property on targets when they are created. Properties ---------- * The "COMPILE_DEFINITIONS" source file property learned to support "generator expressions". * A "COMPILE_OPTIONS" source file property was added to manage list of options to pass to the compiler. * An "IMPORTED_GLOBAL" target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the "GLOBAL" option to "add_library()" or "add_executable()". Additionally, project code may now *promote* a local imported target to be globally visible by setting this property to "TRUE". * An "INCLUDE_DIRECTORIES" source file property was added to specify list of preprocessor include file search directories. * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "CheckIncludeFile" module "check_include_file" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "check_include_files" macro learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command gained a "LANGUAGE" option to specify whether to check using the "C" or "CXX" compiler. * The "CMakePackageConfigHelpers" module "write_basic_package_version_file()" command learned a new "SameMinorVersion" mode for the "COMPATIBILITY" argument. * The "ExternalProject" module learned to substitute "" in comments, commands, working directory and byproducts. * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" options to specify use of a ".netrc" file. * A new "FetchContent" module was added which supports populating content at configure time using any of the download/update methods supported by "ExternalProject_Add()". This allows the content to be used immediately during the configure stage, such as with "add_subdirectory()", etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree. * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME "blis" and "libflame". * The "FindDoxygen" module "doxygen_add_docs()" function now supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any "DOXYGEN_..." variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output "Doxyfile". * A "FindIconv" module was added to locate iconv support. * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command gained an "INCLUDE_GUARD_NAME" option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing "#endif" on the generated export header's include guard. * The "UseJava" module "add_jar" command gained a "GENERATE_NATIVE_HEADERS" option to generate native header files using "javac -h" for "javac" 1.8 or above. This supersedes "create_javah", which no longer works with JDK 1.10 and above due to removal of the "javah" tool by JEP 313. Autogen ------- * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple parallel "moc" or "uic" processes to reduce the build time. A new "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target property may be set to specify the number of parallel "moc" or "uic" processes to start. The default is derived from the number of CPUs on the host. CTest ----- * The "ctest_start()" command no longer sets "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the global scope still prevents the script from being re-run at the end. CPack ----- * "cpack(1)" gained "--trace" and "--trace-expand" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the target directory should not be deleted when uninstalling. * The "CPackRPM" module learned to enable enforcing of execute privileges on programs and shared libraries. See "CPACK_RPM_INSTALL_WITH_EXEC" variable. * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added which serves the same purpose during packaging (e.g. "make package") as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves during installation (e.g. "make install"). Other ----- * Alias Targets may now alias Imported Targets that are created with the "GLOBAL" option to "add_library()". * Interface Libraries may now have custom properties set on them if they start with either an underscore ("_") or a lowercase ASCII character. The original intention was to only allow properties which made sense for "INTERFACE" libraries, but it also blocked usage of custom properties. * The "cmake(1)" "--open " command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0037" through "CMP0054" ("CMP0036" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "KDevelop3" generator has been removed. Other Changes ============= * Policy "CMP0037" no longer reserves target names associated with optional features, such as "test" and "package", unless the corresponding feature is enabled. * The "FindOpenGL" module now prefers GLVND libraries if available. See policy "CMP0072". * The minimum deployment target set in the "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by "CMAKE_OSX_SYSROOT". For example, if the sysroot variable specifies an iOS SDK then the value in "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. * The "Xcode" generator behavior of generating one project file per "project()" command may now be controlled with the "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the "ZERO_CHECK" logic. * Since the "CMakeCache.txt" format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console. ---------------------------------------------------------------------------- Changes made since CMake 3.11.0-rc4: Brad King (5): Features: Record for SunPro 5.15 Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" cmSystemTools: Fix ParseArguments out-of-bounds read ctest_update: Fix crash when handling svn externals CMake 3.11.0 Roger Leigh (1): FindBoost: Add support for Boost 1.67 with Python version suffixes From oliver at revl.com Wed Mar 28 15:12:07 2018 From: oliver at revl.com (Oliver Dain) Date: Wed, 28 Mar 2018 19:12:07 +0000 Subject: [CMake] find_library fails when cross compiling In-Reply-To: References: Message-ID: In case anyone else hits this, I figured it out. The issue was that our toolchain file specified "CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY" which meant it was ignoring our PATH list. Changing it to "CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH" solved the issue. On Mon, Mar 26, 2018 at 6:06 PM Oliver Dain wrote: > Hi, > > I have some find_library lines like the following: > > find_library(protobuf_protobuf protobuf PATHS > /Users/oliverdain/Documents/code/revl/.install/${ARCH}/${VARIANT}/protobuf/3.4.1.r1/lib > NO_DEFAULT_PATH ) > target_link_libraries(ml_editing PUBLIC ${protobuf_protobuf}) > > These work find when $ARCH and $VARIANT are set to OSX and either Debug or > Release (my target system). However, If I run > > cmake -H. > -B/Users/oliverdain/Documents/code/revl/cpp/build/build/IPHONE/Release > -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DIOS_PLATFORM=OS > -DCMAKE_BUILD_TYPE=Release -DARCH=IPHONE -DVARIANT=Release > > the libraries are reported not found (the standard "CMake Error: The > following variables are used in this project, but they are set to > NOTFOUND." error) even though the libraries are in the specified location. > For example, it says it can't find the protobuf libs but an ls yields: > > $ ls > /Users/oliverdain/Documents/code/revl/.install/IPHONE/Release/protobuf/3.4.1.r1/lib > cmake libprotobuf-lite.a libprotobuf.a pkgconfig > > Note that if I change the NO_DEFAULT_PATH specification in the > find_library line to NO_CMAKE_FIND_ROOT_PATH everything works as expected > and the libs are found and linked (and I know its the right libs because > things also run). > > Is this a bug or is there something I don't understand about > NO_DEFAULT_PATH? > > Thanks, > Oliver > > PS: I know the hard coded full path names are odd - the CMakeLists.txt > files are actually generated -- it's a long story. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Thu Mar 29 20:08:44 2018 From: pfultz2 at yahoo.com (P F) Date: Thu, 29 Mar 2018 19:08:44 -0500 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <5ABA36EC.1000007@hiroshima-u.ac.jp> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> Message-ID: <0C462488-C858-4FD9-AAC9-79910891C662@yahoo.com> The BCM(boost cmake modules) has `bcm_auto_pkgconfig` which will generate the pkgconfig file from a target, including the ?Require? variable: http://bcm.readthedocs.io/en/latest/src/BCMPkgConfig.html#bcm-auto-pkgconfig It utilizes the `INTERFACE_PKG_CONFIG_NAME` property to generate the pkgconfig names for the dependent targets: http://bcm.readthedocs.io/en/latest/src/BCMProperties.html#interface-pkg-config-name Currently, it doesn't coordinate with FindPkgConfig?s imported targets yet, so you will need to manually inject the name. However, when using `bcm_auto_export` it will export the property, so that when users finds the dependency with `find_package`, it knows the corresponding pkgconfig module. > On Mar 27, 2018, at 7:19 AM, suzuki toshiya > wrote: > > Hi all, > > I'm looking for 2 features to generate pkg-config pc files. > I already wrote something, but some experts advised that there > would be many people trying to do such, and there might be existing > solution. If such functions are already included in cmake's > official modules, please let me know. Of course, combination > of existing functions would be OK. > > function 1) > ----------- > > ...is trying to find an available pkg-config module name from a > list of several candidates. the typical usecase would be a > search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? > libjpeg9? libjpeg62? ...). getting a name of module is important > to write "Require" variable of pc file. > > there is already pkg_search_module() searching an available module > from a list, but it does not return the name of found module. > thus it cannot help to write "Require" variable. > > what I wrote is something like this. > > # > # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) > # > # there is pkg_search_module(), but it does not clarify > # which module was found. > # > # this function does not set xxx_CFLAGS xxx_LIBS etc. > # > # use like: > # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG > "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") > # > function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) > set(_PKG_FOUND FALSE) > foreach(_pkg IN LISTS pkg_list) > pkg_check_modules(_PKG "${_pkg}") > if (_PKG_FOUND) > set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) > set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) > return() > endif() > endforeach(_pkg) > endfunction(PKG_SEARCH_AVAILABLE_MODULE) > > function 2) > ----------- > ...makes something like LDFLAGS + LIBS from the pathnames of libraries. > some library finders of cmake do not return "-L/xxx -lyyy" values > but returns "/xxx/libyyy.so". pkg-config has some difficulties > to hold such raw pathnames of the libraries (e.g. pkg-config > use "Libs" variable for both of static and shared linking, > thus having "libxxx.a" or "libxxx.so" explicitly is not good), > so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". > > what I wrote is something like this: > > # > # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) > # > function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) > foreach(_libpath IN LISTS _libpaths) > string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") > > string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") > string(REGEX REPLACE > "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib > "${_lib}") > string(REGEX REPLACE "^lib" "" _lib "${_lib}") > > set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} > ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") > endforeach(_libpath) > set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) > endfunction(MAKE_LDFLAGS_FROM_LIBPATH) > > Regards, > mpsuzuki > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Thu Mar 29 21:54:07 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Fri, 30 Mar 2018 10:54:07 +0900 Subject: [CMake] looking for 2 features to help pkg-config pc files In-Reply-To: <65a101796d634fdaaf02598d9c5c7e86@OS2PR01MB1147.jpnprd01.prod.outlook.com> References: <5ABA36EC.1000007@hiroshima-u.ac.jp> <65a101796d634fdaaf02598d9c5c7e86@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <24a1b312-3be0-8d32-f626-c039c0964381@hiroshima-u.ac.jp> Dear Paul Fultz, Great, I will take a look. I'm glad to hear that you're also working on this issue! Regards, mpsuzuki On 3/30/2018 9:08 AM, P F wrote: > The BCM(boost cmake modules) has `bcm_auto_pkgconfig` which will generate the pkgconfig file from a target, including the ?Require? variable: > > http://bcm.readthedocs.io/en/latest/src/BCMPkgConfig.html#bcm-auto-pkgconfig > > It utilizes the `INTERFACE_PKG_CONFIG_NAME` property to generate the pkgconfig names for the dependent targets: > > http://bcm.readthedocs.io/en/latest/src/BCMProperties.html#interface-pkg-config-name > > Currently, it doesn't coordinate with FindPkgConfig?s imported targets yet, so you will need to manually inject the name. However, when using `bcm_auto_export` it will export the property, so that when users finds the dependency with `find_package`, it knows the corresponding pkgconfig module. > > On Mar 27, 2018, at 7:19 AM, suzuki toshiya > wrote: > > Hi all, > > I'm looking for 2 features to generate pkg-config pc files. > I already wrote something, but some experts advised that there > would be many people trying to do such, and there might be existing > solution. If such functions are already included in cmake's > official modules, please let me know. Of course, combination > of existing functions would be OK. > > function 1) > ----------- > > ...is trying to find an available pkg-config module name from a > list of several candidates. the typical usecase would be a > search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo? > libjpeg9? libjpeg62? ...). getting a name of module is important > to write "Require" variable of pc file. > > there is already pkg_search_module() searching an available module > from a list, but it does not return the name of found module. > thus it cannot help to write "Require" variable. > > what I wrote is something like this. > > # > # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules]) > # > # there is pkg_search_module(), but it does not clarify > # which module was found. > # > # this function does not set xxx_CFLAGS xxx_LIBS etc. > # > # use like: > # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG > "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62") > # > function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list) > set(_PKG_FOUND FALSE) > foreach(_pkg IN LISTS pkg_list) > pkg_check_modules(_PKG "${_pkg}") > if (_PKG_FOUND) > set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE) > set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE) > return() > endif() > endforeach(_pkg) > endfunction(PKG_SEARCH_AVAILABLE_MODULE) > > function 2) > ----------- > ...makes something like LDFLAGS + LIBS from the pathnames of libraries. > some library finders of cmake do not return "-L/xxx -lyyy" values > but returns "/xxx/libyyy.so". pkg-config has some difficulties > to hold such raw pathnames of the libraries (e.g. pkg-config > use "Libs" variable for both of static and shared linking, > thus having "libxxx.a" or "libxxx.so" explicitly is not good), > so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy". > > what I wrote is something like this: > > # > # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath]) > # > function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths) > foreach(_libpath IN LISTS _libpaths) > string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}") > > string(REGEX REPLACE "^.*/" "" _lib "${_libpath}") > string(REGEX REPLACE > "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib > "${_lib}") > string(REGEX REPLACE "^lib" "" _lib "${_lib}") > > set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir} > ${CMAKE_LINK_LIBRARY_FLAG}${_lib}") > endforeach(_libpath) > set("${_ldflags}" "${__ldflags}" PARENT_SCOPE) > endfunction(MAKE_LDFLAGS_FROM_LIBPATH) > > Regards, > mpsuzuki > > -- > > 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 > > From isaiah.norton at gmail.com Fri Mar 30 13:27:46 2018 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Fri, 30 Mar 2018 13:27:46 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.11.0 available for download In-Reply-To: References: Message-ID: > > A "CMAKE_JOB_POOLS" variable was added specify a value to use for > the "JOB_POOLS" property. This enables control over build > parallelism with command line configuration parameters when using > the Ninja generator. > Does this work with ExternalProject sub-builds? If not, I would suggest a big warning sign on the flag will save some headache... (my limited understanding of ninja's job pool implementation leads me to think not -- that would need jobserver support, the PR for which has languished. Would be very happy to learn otherwise!) On Wed, Mar 28, 2018 at 2:14 PM, Robert Maynard wrote: > I am proud to announce that CMake 3.11.0 is now available for download at: > https://cmake.org/download/ > > Documentation is available at: > https://cmake.org/cmake/help/v3.11 > > Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.11/release/3.11.html > > Some of the more significant changes in CMake 3.11 are: > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CMake 3.11 Release Notes > ************************ > > Changes made since CMake 3.10 include the following. > > > New Features > ============ > > > Platforms > --------- > > * TI C/C++ compilers are now supported by the "Ninja" generator. > > > Generators > ---------- > > * The "CodeBlocks" extra generator learned to check a > "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler > identification value to place in the project file. > > * The Makefile Generators and the "Ninja" generator learned to add > compiler launcher tools along with the compiler for the "Fortran" > language ("C", "CXX", and "CUDA" were supported previously). See the > "CMAKE__COMPILER_LAUNCHER" variable and > "_COMPILER_LAUNCHER" target property for details. > > * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS", > "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See > generator expression documentation for caveats. > > * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" > "generator expression" in target-wide "COMPILE_DEFINITIONS" and > "INCLUDE_DIRECTORIES". It previously supported only > "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression > documentation for caveats. > > > Commands > -------- > > * "add_library()" and "add_executable()" commands can now be called > without any sources and will not complain as long as sources are > added later via the "target_sources()" command. > > * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" > and "NETRC_FILE" options to specify use of a ".netrc" file. > > * The "target_compile_definitions()" command learned to set the > "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. > > * The "target_compile_features()" command learned to set the > "INTERFACE_COMPILE_FEATURES" property on Imported Targets. > > * The "target_compile_options()" command learned to set the > "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. > > * The "target_include_directories()" command learned to set the > "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. > > * The "target_sources()" command learned to set the > "INTERFACE_SOURCES" property on Imported Targets. > > * The "target_link_libraries()" command learned to set the > "INTERFACE_LINK_LIBRARIES" property on Imported Targets. > > > Variables > --------- > > * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the > selected instance of the generator's corresponding native tools if > multiple are available. This is used by the "Visual Studio 15 2017" > generator to hold the selected instance of Visual Studio > persistently. > > * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > to enable setting of default permissions for directories created > implicitly during installation of files by "install()" and > "file(INSTALL)", e.g. during "make install". > > * A "CMAKE_JOB_POOLS" variable was added specify a value to use for > the "JOB_POOLS" property. This enables control over build > parallelism with command line configuration parameters when using > the Ninja generator. > > * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to > specify use of a ".netrc" file by the "file(DOWNLOAD)" and > "file(UPLOAD)" commands and the "ExternalProject" module. > > * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to > initialize the "CUDA_SEPARABLE_COMPILATION" target property on > targets when they are created. > > > Properties > ---------- > > * The "COMPILE_DEFINITIONS" source file property learned to support > "generator expressions". > > * A "COMPILE_OPTIONS" source file property was added to manage list > of options to pass to the compiler. > > * An "IMPORTED_GLOBAL" target property was added to indicate whether > an IMPORTED target is globally visible. It is automatically set to a > true value for targets created with the "GLOBAL" option to > "add_library()" or "add_executable()". Additionally, project code > may now *promote* a local imported target to be globally visible by > setting this property to "TRUE". > > * An "INCLUDE_DIRECTORIES" source file property was added to specify > list of preprocessor include file search directories. > > * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and > "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of > ".hlsl" sources with Visual Studio Generators. > > > Modules > ------- > > * The "CheckIncludeFile" module "check_include_file" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro > learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "check_include_files" macro learned > to honor the "CMAKE_REQUIRED_LIBRARIES" variable. > > * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command > gained a "LANGUAGE" option to specify whether to check using the "C" > or "CXX" compiler. > > * The "CMakePackageConfigHelpers" module > "write_basic_package_version_file()" command learned a new > "SameMinorVersion" mode for the "COMPATIBILITY" argument. > > * The "ExternalProject" module learned to substitute > "" in comments, commands, working directory and > byproducts. > > * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" > options to specify use of a ".netrc" file. > > * A new "FetchContent" module was added which supports populating > content at configure time using any of the download/update methods > supported by "ExternalProject_Add()". This allows the content to be > used immediately during the configure stage, such as with > "add_subdirectory()", etc. Hierarchical project structures are well > supported, allowing parent projects to override the content details > of child projects and ensuring content is not populated multiple > times throughout the whole project tree. > > * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME > "blis" and "libflame". > > * The "FindDoxygen" module "doxygen_add_docs()" function now > supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any > "DOXYGEN_..." variable contained in that list will bypass the > automatic quoting logic, leaving its contents untouched when > transferring them to the output "Doxyfile". > > * A "FindIconv" module was added to locate iconv support. > > * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command > gained an "INCLUDE_GUARD_NAME" option to change the name of the > include guard symbol written to the generated export header. > Additionally, it now adds a comment after the closing "#endif" on > the generated export header's include guard. > > * The "UseJava" module "add_jar" command gained a > "GENERATE_NATIVE_HEADERS" option to generate native header files > using "javac -h" for "javac" 1.8 or above. This supersedes > "create_javah", which no longer works with JDK 1.10 and above due to > removal of the "javah" tool by JEP 313. > > > Autogen > ------- > > * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple > parallel "moc" or "uic" processes to reduce the build time. A new > "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target > property may be set to specify the number of parallel "moc" or "uic" > processes to start. The default is derived from the number of CPUs > on the host. > > > CTest > ----- > > * The "ctest_start()" command no longer sets > "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is > called from inside a function. Instead, it sets an internal variable > in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the > global scope still prevents the script from being re-run at the end. > > > CPack > ----- > > * "cpack(1)" gained "--trace" and "--trace-expand" options. > > * The "CPackIFW" module gained new > "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the > target directory should not be deleted when uninstalling. > > * The "CPackRPM" module learned to enable enforcing of execute > privileges on programs and shared libraries. See > "CPACK_RPM_INSTALL_WITH_EXEC" variable. > > * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added > which serves the same purpose during packaging (e.g. "make package") > as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves > during installation (e.g. "make install"). > > > Other > ----- > > * Alias Targets may now alias Imported Targets that are created with > the "GLOBAL" option to "add_library()". > > * Interface Libraries may now have custom properties set on them if > they start with either an underscore ("_") or a lowercase ASCII > character. The original intention was to only allow properties which > made sense for "INTERFACE" libraries, but it also blocked usage of > custom properties. > > * The "cmake(1)" "--open " command-line option was added to > open generated IDE projects like Visual Studio solutions or Xcode > projects. > > > Deprecated and Removed Features > =============================== > > * An explicit deprecation diagnostic was added for policies > "CMP0037" through "CMP0054" ("CMP0036" and below were already > deprecated). The "cmake-policies(7)" manual explains that the OLD > behaviors of all policies are deprecated and that projects should > port to the NEW behaviors. > > * The "KDevelop3" generator has been removed. > > > Other Changes > ============= > > * Policy "CMP0037" no longer reserves target names associated with > optional features, such as "test" and "package", unless the > corresponding feature is enabled. > > * The "FindOpenGL" module now prefers GLVND libraries if available. > See policy "CMP0072". > > * The minimum deployment target set in the > "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for > macOS regardless of the selected SDK. It is now properly set for > the target platform selected by "CMAKE_OSX_SYSROOT". For example, if > the sysroot variable specifies an iOS SDK then the value in > "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. > > * The "Xcode" generator behavior of generating one project file per > "project()" command may now be controlled with the > "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could > be useful to speed up the CMake generation step for large projects > and to work-around a bug in the "ZERO_CHECK" logic. > > * Since the "CMakeCache.txt" format does not support newlines in > values, values containing newlines are now truncated before writing > to the file. In addition, a warning comment is written to the cache > file, and a warning message is displayed to the user on the console. > > ------------------------------------------------------------ > ---------------- > Changes made since CMake 3.11.0-rc4: > > Brad King (5): > Features: Record for SunPro 5.15 > Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" > cmSystemTools: Fix ParseArguments out-of-bounds read > ctest_update: Fix crash when handling svn externals > CMake 3.11.0 > > Roger Leigh (1): > FindBoost: Add support for Boost 1.67 with Python version suffixes > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.e.brownsword at gmail.com Fri Mar 30 15:06:51 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Fri, 30 Mar 2018 12:06:51 -0700 Subject: [CMake] find_package not finding Threads Message-ID: I have an Ubuntu 16.04 ARMv7 system upon which I have built CLang 7.0 and am now trying to use it to build my CMake-based project that was previously working with the CLang 3.8.0 that I had installed via apt-get. The new compiler does appear to be selected correctly when I run cmake. The run fails when it tries this find_package call: set(THREADS_PREFER_PTHREAD_FLAG ON) find_package(Threads REQUIRED) With this error: CMake Error at /usr/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Threads (missing: Threads_FOUND) Call Stack (most recent call first): /usr/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) /usr/local/share/cmake-3.8/Modules/FindThreads.cmake:212 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) src/libraries/civetweb/CMakeLists.txt:8 (find_package) The libpthread.so resides in /usr/lib/arm-linux-gnueabihf/ on this system. I am *not* cross-compiling, and I built CLang on the system itself. I?ve looked at the REGEX that CMake is supposed to use to find this subdirectory and it looks correct (and it did work with CLang 3.8.0). Any suggestions? The CMakeError.log file contains this: Determining if the pthread_create exist failed with the following output: Change Dir: ~/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_1d4b8/fast" /usr/bin/make -f CMakeFiles/cmTC_1d4b8.dir/build.make CMakeFiles/cmTC_1d4b8.dir/build make[1]: Entering directory '~/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o /usr/bin/clang -Wall -fno-strict-aliasing -o CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o -c ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c Linking C executable cmTC_1d4b8 /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_1d4b8.dir/link.txt --verbose=1 /usr/bin/clang -Wall -fno-strict-aliasing CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o -o cmTC_1d4b8 CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o: In function `main': ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x4): undefined reference to `pthread_create' ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x8): undefined reference to `pthread_create' ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x24): undefined reference to `pthread_create' ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x28): undefined reference to `pthread_create' clang: error: linker command failed with exit code 1 (use -v to see invocation) CMakeFiles/cmTC_1d4b8.dir/build.make:97: recipe for target 'cmTC_1d4b8' failed make[1]: *** [cmTC_1d4b8] Error 1 make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_1d4b8/fast' failed make: *** [cmTC_1d4b8/fast] Error 2 File ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /* */ #include int main(int argc, char** argv) { (void)argv; #ifndef pthread_create return ((int*)(&pthread_create))[argc]; #else (void)argc; return 0; #endif } Determining if the function pthread_create exists in the pthreads failed with the following output: Change Dir: ~/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_81507/fast" /usr/bin/make -f CMakeFiles/cmTC_81507.dir/build.make CMakeFiles/cmTC_81507.dir/build make[1]: Entering directory '~/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o /usr/bin/clang -Wall -fno-strict-aliasing -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o -c /usr/local/share/cmake-3.8/Modules/CheckFunctionExists.c Linking C executable cmTC_81507 /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_81507.dir/link.txt --verbose=1 /usr/bin/clang -Wall -fno-strict-aliasing -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o -o cmTC_81507 -lpthreads /usr/bin/ld: cannot find -lpthreads clang: error: linker command failed with exit code 1 (use -v to see invocation) CMakeFiles/cmTC_81507.dir/build.make:97: recipe for target 'cmTC_81507' failed make[1]: *** [cmTC_81507] Error 1 make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_81507/fast' failed make: *** [cmTC_81507/fast] Error 2 Determining if the include file pthread.h exists failed with the following output: Change Dir: ~/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_83cc7/fast" /usr/bin/make -f CMakeFiles/cmTC_83cc7.dir/build.make CMakeFiles/cmTC_83cc7.dir/build make[1]: Entering directory '~/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o /usr/local/bin/clang -Wall -fno-strict-aliasing -o CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o -c ~/CMakeFiles/CMakeTmp/CheckIncludeFile.c In file included from ~/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1: In file included from /usr/include/pthread.h:23: /usr/include/sched.h:28:10: fatal error: 'stddef.h' file not found #include ^~~~~~~~~~ 1 error generated. CMakeFiles/cmTC_83cc7.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o' failed make[1]: *** [CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o] Error 1 make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_83cc7/fast' failed make: *** [cmTC_83cc7/fast] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.e.brownsword at gmail.com Fri Mar 30 15:12:06 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Fri, 30 Mar 2018 12:12:06 -0700 Subject: [CMake] Failure to build CMake 3.11.0 on ARMv7 Ubuntu 16.04 due to std::size undefined Message-ID: I am attempting to build the latest release of CMake on my ARM-based Ubuntu system. The bootstrap works fine, however the make fails with a bunch of error messages which all look like variations on this one: In file included from /home/andrew/cmake/cmake-3.11.0/Source/cmCryptoHash.cxx:5: /home/andrew/cmake/cmake-3.11.0/Source/cmAlgorithms.h:407:7: error: no member named 'size' in namespace 'std'; did you mean 'std::seed_seq::size'? using std::size; ^~~~~~~~~ std::seed_seq::size Looking at the source the compiler is checking the __cplusplus macro to see if it is 2017-something, and it apparently passes this test when I make CMake. If I just write a trivial program that prints this define, it outputs 201500L. The compiler in use is the system gcc compiler, version 5.4.0. I?ve tried it with the CLang 7.0 compiler I just built and get the same errors. Any suggestions? From tapika at yahoo.com Sat Mar 31 04:19:11 2018 From: tapika at yahoo.com (Tarmo Pikaro) Date: Sat, 31 Mar 2018 08:19:11 +0000 (UTC) Subject: [CMake] cmake analogue - syncProj visual studio generation tool References: <1362412393.86672.1522484352002.ref@mail.yahoo.com> Message-ID: <1362412393.86672.1522484352002@mail.yahoo.com> Hi ! On my own free time I've managed to create tool similar to cmake - command line tool called syncProj. Currently syncProj is aiming also for portability, but it currently has narrower list of supported platforms - supported platforms are at this moment only Windows and Android, butonly Visual studio based. Where cmake is using special kind of language, syncProj uses C# programming language as a base, and because of this allows full support forsyncProj C# script code syntax highlighting, intellisense and full debug support. Documentation:https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# Source code:https://sourceforge.net/projects/syncproj syncProj is something that was just born on the way of making another project, and I suspect that it's far from supporting?all visual studio project parameters and configurations, but it provides solid code base for future development. So if you're familiar with C# or not familiar, but willing to learn, feel free to contact me, I can guide in syncProj code baseand teach you how to improve syncProj. Currently syncProj supports C++, but not C#, as a platform base runs only on Windows, and limited to Windows / Android platforms. What I have checked through Visual studio even currently start to support Linux based platforms, so if you want to or need that platform,?I can guide you through how to add that support into syncProj. Current code coverage level is?83.23%?and I plan to increase that value with each future change. ------------------- Future considerations ---------------------- Currently I see syncProj as intermediate solution or a tool - I think in future syncProj could actually become built-in into Visual studio itself,as base class hierachy - something similar Microsoft guys are trying to achieve right now by integrating cmake initial support into Visual studio. cmake scripting language dialect is more difficult to learn than C#, but of course ideal world would be if C++ project would be configured?using C++ "script" syntax. But at the moment C# allows on-fly compiling of C# code, but not C++. I think that through making C++ modules possible +?allowing to compile C++ immediately - this would permit to make new variation of syncProj, which would be coded in C++ fully, but this is somethingto consider later on, after C++ modules starts working in full scale on multiple compilers. -- Have a nice day!? ? ?Tarmo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Sat Mar 31 05:02:43 2018 From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Sat, 31 Mar 2018 11:02:43 +0200 Subject: [CMake] cmake analogue - syncProj visual studio generation tool In-Reply-To: <1362412393.86672.1522484352002@mail.yahoo.com> References: <1362412393.86672.1522484352002.ref@mail.yahoo.com> <1362412393.86672.1522484352002@mail.yahoo.com> Message-ID: <1522486963.3375.95.camel@bockemuehl.ch> Hello Tarmo, Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake? At the same time I think that _answering_ this question is probably not a subject that fits into the CMake mailing list because it is obviously for CMake issues, not ads for alternatives. So in this sense my question is rhetoric only... ;-) Providing a link to further documentation (like you are doing!) is certainly enough here - and I can see that there is the one or other function that CMake does not offer. I am not asking _why_ you are writing this at all! If you are doing this in your free time I understand 100% the fun it is to re-invent the one or other wheel: I did that many times in the past, so I assume that I understand pretty well... On the other hand: Just think about the fact that CMake is indeed Open Source! It means not more and not less than that nobody is constrained to the functionality that some "gods" are offering (like it is the case with the MS Visual Studio - mostly), but you would be able to add the things that you are missing and build on the many available features that others have implemented so far - and which you will have to rewrite for your project from scratch. In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-) So in short: Thanks for the free offer, but I don't need it because I have CMake! Regards, Cornelis Am Samstag, den 31.03.2018, 08:19 +0000 schrieb Tarmo Pikaro via CMake: > Hi ! > > > > On my own free time I've managed to create tool similar to cmake - command line tool called syncProj. > > > > > Currently syncProj is aiming also for portability, but it currently has narrower list of supported platforms - supported platforms are at this moment only Windows and Android, but > only Visual studio based. > > > > Where cmake is using special kind of language, syncProj uses C# programming language as a base, and because of this allows full support for > > syncProj C# script code syntax highlighting, intellisense and full debug support. > > Documentation: > > https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rC lyknBj5zHU/edit# > > > Source code: > https://sourceforge.net/projects/syncproj > > > syncProj is something that was just born on the way of making another project, and I suspect that it's far from supporting? > > all visual studio project parameters and configurations, but it provides solid code base for future development. > > > So if you're familiar with C# or not familiar, but willing to learn, feel free to contact me, I can guide in syncProj code base > and teach you how to improve syncProj. > > > Currently syncProj supports C++, but not C#, as a platform base runs only on Windows, and limited to Windows / Android platforms. > > > > What I have checked through Visual studio even currently start to support Linux based platforms, so if you want to or need that platform,? > I can guide you through how to add that support into syncProj. > > > Current code coverage level is?83.23%?and I plan to increase that value with each future change. > > ------------------- Future considerations ---------------------- > > > > Currently I see syncProj as intermediate solution or a tool - I think in future syncProj could actually become built-in into Visual studio itself, > > > as base class hierachy - something similar Microsoft guys are trying to achieve right now by integrating cmake initial support into Visual studio. > > > > cmake scripting language dialect is more difficult to learn than C#, but of course ideal world would be if C++ project would be configured? > using C++ "script" syntax. > > > But at the moment C# allows on-fly compiling of C# code, but not C++. I think that through making C++ modules possible +? > > > allowing to compile C++ immediately - this would permit to make new variation of syncProj, which would be coded in C++ fully, but this is something > > to consider later on, after C++ modules starts working in full scale on multiple compilers. > > > --????Have a nice day!? ? ?Tarmo. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tapika at yahoo.com Sat Mar 31 12:08:16 2018 From: tapika at yahoo.com (Tarmo Pikaro) Date: Sat, 31 Mar 2018 16:08:16 +0000 (UTC) Subject: [CMake] cmake analogue - syncProj visual studio generation tool In-Reply-To: <1522486963.3375.95.camel@bockemuehl.ch> References: <1362412393.86672.1522484352002.ref@mail.yahoo.com> <1362412393.86672.1522484352002@mail.yahoo.com> <1522486963.3375.95.camel@bockemuehl.ch> Message-ID: <138755966.155158.1522512496534@mail.yahoo.com> Hi ! >?Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake? Basically once new tool is created,? tool establish it's own community around it - and like with religion, it's difficult to?turn religious people around or convince them to use other tool.? Key advantage of syncProj, is that as scripting language youwill use full dialect of C# - that means you can read / write files using normal C# language, you can probe anything you want,from files or from registry, and you have built-in RegEx if you need to parse or extract anything what is needed.Also any version file generation, or any file generation is also relatively simple - use StringBuilder (C#, built-in).Xml or Json parsing is also simple, also built in. But I think main key advantage over cmake is ability to debug project generation script itself, and having full supportfor intellisense (offered by Visual studio). >?On the other hand: Just think about the fact that CMake is indeed Open Source! Also syncProj is fully open source code - I haven't placed any license, but I will add MIT license later on. > In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-)> So in short: Thanks for the free offer, but I don't need it because I have CMake! I would prefer to avoid using different associations or getting emotional in this chat. syncProj is a small tool, my own prototype.Even thus it's small, it can do much more already what cmake cannot do. Want to use it - use it, don't want to use it - then don't use it. It's a simple like that. I would prefer not to fight against cmake, but maybe check what we could have in common (maybe unit / integration testing ?).My vision is to have C++ as a base code in syncProj, but I will probably need C++ 2018 - ... features.? -- Have a nice day!? ? ?Tarmo. From: Cornelis Bockem?hl To: Tarmo Pikaro ; "cmake at cmake.org" Sent: Saturday, March 31, 2018 12:02 PM Subject: Re: [CMake] cmake analogue - syncProj visual studio generation tool Hello Tarmo, Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake? At the same time I think that _answering_ this question is probably not a subject that fits into the CMake mailing list because it is obviously for CMake issues, not ads for alternatives. So in this sense my question is rhetoric only... ;-) Providing a link to further documentation (like you are doing!) is certainly enough here - and I can see that there is the one or other function that CMake does not offer. I am not asking _why_ you are writing this at all! If you are doing this in your free time I understand 100% the fun it is to re-invent the one or other wheel: I did that many times in the past, so I assume that I understand pretty well... On the other hand: Just think about the fact that CMake is indeed Open Source! It means not more and not less than that nobody is constrained to the functionality that some "gods" are offering (like it is the case with the MS Visual Studio - mostly), but you would be able to add the things that you are missing and build on the many available features that others have implemented so far - and which you will have to rewrite for your project from scratch. In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-) So in short: Thanks for the free offer, but I don't need it because I have CMake! Regards,Cornelis Am Samstag, den 31.03.2018, 08:19 +0000 schrieb Tarmo Pikaro via CMake: Hi ! On my own free time I've managed to create tool similar to cmake - command line tool called syncProj. Currently syncProj is aiming also for portability, but it currently has narrower list of supported platforms - supported platforms are at this moment only Windows and Android, butonly Visual studio based. Where cmake is using special kind of language, syncProj uses C# programming language as a base, and because of this allows full support forsyncProj C# script code syntax highlighting, intellisense and full debug support. Documentation:https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# Source code:https://sourceforge.net/projects/syncproj syncProj is something that was just born on the way of making another project, and I suspect that it's far from supporting?all visual studio project parameters and configurations, but it provides solid code base for future development. So if you're familiar with C# or not familiar, but willing to learn, feel free to contact me, I can guide in syncProj code baseand teach you how to improve syncProj. Currently syncProj supports C++, but not C#, as a platform base runs only on Windows, and limited to Windows / Android platforms. What I have checked through Visual studio even currently start to support Linux based platforms, so if you want to or need that platform,?I can guide you through how to add that support into syncProj. Current code coverage level is?83.23%?and I plan to increase that value with each future change. ------------------- Future considerations ---------------------- Currently I see syncProj as intermediate solution or a tool - I think in future syncProj could actually become built-in into Visual studio itself,as base class hierachy - something similar Microsoft guys are trying to achieve right now by integrating cmake initial support into Visual studio. cmake scripting language dialect is more difficult to learn than C#, but of course ideal world would be if C++ project would be configured?using C++ "script" syntax. But at the moment C# allows on-fly compiling of C# code, but not C++. I think that through making C++ modules possible +?allowing to compile C++ immediately - this would permit to make new variation of syncProj, which would be coded in C++ fully, but this is somethingto consider later on, after C++ modules starts working in full scale on multiple compilers. -- Have a nice day!? ? ?Tarmo. -------------- next part -------------- An HTML attachment was scrubbed... URL: