From robert.maynard at kitware.com Mon Apr 1 16:11:07 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 1 Apr 2019 16:11:07 -0400 Subject: [CMake] Does enable_language(CUDA) still have the problem with reconfiguring? In-Reply-To: <2c1c038a-9a70-8a69-8ab2-afc88050f8bd@txcorp.com> References: <2c1c038a-9a70-8a69-8ab2-afc88050f8bd@txcorp.com> Message-ID: It doesn't have this behavior. For Makefile and Ninja generators we get the proper header dependencies at compile time just like we do for C or C++. For MSBuild we rely on the CUDA extensions written by nvidia which do proper dependency tracking. On Sat, Mar 30, 2019 at 4:12 PM JR Cary wrote: > > Re the thread below, > > Does the newer, enable_languagedo a better job of not having the > repeated reconfigurations and full project rebuilds as described at > > https://cmake.org/pipermail/cmake/2011-January/042173.html > > and many times after? > > John > > > > On 3/30/19 6:45 AM, cmake-request at cmake.org wrote: > > ----------------------------- > > Message: 4 > > Date: Sat, 30 Mar 2019 12:45:07 +0000 > > From: Luis Caro Campos > > > > I believe the closest equivalent to settinga CUDA_TOOLKIT_ROOT_DIR when > > using enable_language(CUDA) is to set either the environment variable > > CUDACXX or the CMake cache entry CMAKE_CUDA_COMPILER to point to the > > location of the nvcc compiler. > > > > However I think there are still some "features" of FindCUDA that > > enable_language don't support, e.g. variables and/or import targets with > > locations, see https://gitlab.kitware.com/cmake/cmake/issues/17816 > > > > Kind regards, > > Luis > > > > On Fri, Mar 29, 2019 at 4:57 PM Dustyn Blasig wrote: > > > >> "we should not try to combine enable_language(CUDA) with > >> find_package(CUDA). They do not work together, either use one or another." > >> > >> Absolutely, my goal is to move to the new built-in language support. I'm > >> having trouble doing that because I can't find any documentation on it. For > >> instance, what is the new equivalent CUDA_TOOLKIT_ROOT_DIR? Without > >> find_package(CUDA), I don't see anything set that have the equivalent. > >> Also, in some cases the CUDA include directory is added to targets, and in > >> other cases it isn't, even if the target depends on source with .cu. What > >> is the documented behavior for this? > >> > >> I'm sure there has to be a page somewhere on this, but going to page 4 on > >> Google search didn't uncover anything, and the first 2 pages all point to > >> various versions of FindCUDA : ) > >> > >> On Fri, Mar 29, 2019 at 11:28 AM Dmitry Mikushin < > >> dmitry at parallel-computing.pro> wrote: > >> > >>> Hi, > >>> > >>> That was my confusion as well: to my understanding, we should not try to > >>> combine enable_language(CUDA) with find_package(CUDA). They do not work > >>> together, either use one or another. > >>> > >>> Kind regards, > >>> - Dmitry. > >>> > >>> ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : > >>> > >>>> Hi All, > >>>> > >>>> I can't find any documentation on the new-ish "native" CUDA support. I > >>>> need to know all the variables that we can use, and (for instance) whether > >>>> checking the CUDA version is now supported. When searching online, I'm > >>>> always directed to the old FindCUDA pages which don't seem to match what is > >>>> available with the native language support. > >>>> > >>>> Currently, I'm "hacking" my way through things by using both flows. I > >>>> add CUDA as a language, use the found CUDA compiler to construct a > >>>> CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old > >>>> environment variables set up. > >>>> > >>>> Cheers! > >>>> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From mojca.miklavec.lists at gmail.com Mon Apr 1 17:02:41 2019 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Mon, 1 Apr 2019 23:02:41 +0200 Subject: [CMake] Does enable_language(CUDA) still have the problem with reconfiguring? In-Reply-To: References: <2c1c038a-9a70-8a69-8ab2-afc88050f8bd@txcorp.com> Message-ID: On Mon, 1 Apr 2019 at 22:11, Robert Maynard via CMake wrote: > > For MSBuild we rely on the CUDA extensions written by nvidia which do > proper dependency tracking. Except when they don't. It drove me nearly crazy that any given trivial change had to be followed by a complete rebuild of the project. But I see that someone commented an hour ago: https://stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files saying that the fix has finally arrived (in March). Mojca From robert.maynard at kitware.com Mon Apr 1 17:11:16 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 1 Apr 2019 17:11:16 -0400 Subject: [CMake] Does enable_language(CUDA) still have the problem with reconfiguring? In-Reply-To: References: <2c1c038a-9a70-8a69-8ab2-afc88050f8bd@txcorp.com> Message-ID: Yes, we are dependent on the CUDA extensions for ms-build working correctly. On Mon, Apr 1, 2019 at 5:02 PM Mojca Miklavec wrote: > > On Mon, 1 Apr 2019 at 22:11, Robert Maynard via CMake wrote: > > > > For MSBuild we rely on the CUDA extensions written by nvidia which do > > proper dependency tracking. > > Except when they don't. It drove me nearly crazy that any given > trivial change had to be followed by a complete rebuild of the > project. > > But I see that someone commented an hour ago: > https://stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files > saying that the fix has finally arrived (in March). > > Mojca From stephan.menzel at gmail.com Tue Apr 2 00:54:34 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Tue, 2 Apr 2019 05:54:34 +0100 Subject: [CMake] Fake dependencies of executables to static libs Message-ID: Hello List, In our projects we are using static linkage on Windows (MSVC) and Linux. A number of static libs are created and then linked into executables, such as unit tests, tools and the actual production artifacts. Very normal stuff. add_library(mylib STATIC mysources) add_excecutable(mytest mytest.cpp) target_link_libraries(mytest mylib) Now although I don't understand the exact reasons behind that, over the years came to accept that depedencies between the lib and the resulting artifcats are not working. Like, when I change a source file to mylib, the lib will get rebuilt but the resulting test tool won't be relinked. For test driven development or busy change cycles that can put quite a strain on effort, especially on windows. My normal workflow is that I always click in mytest.cpp, add and remove a space to mark it dirty as quickly as possible and thereby cause the rebuild. But sometimes I forget this and this caused me quite a bit of extra work. My question is, can I fake that dependency somehow? Perhaps by some hack or using some workaround? What I want to achieve is that when I change the lib, the unit test (or any other test tool using it) that depends on it will be relinked, even if it has not changed. Is that possible somehow? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Tue Apr 2 12:04:06 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Tue, 2 Apr 2019 09:04:06 -0700 Subject: [CMake] Eclipse generator question Message-ID: I've recently converted a complex C++ codebase to CMake. I'm stuck using 2.8.12.2. The codebase has a source tree, whose leaf directories each build a shared library or an executable binary. The source lives in src/ while the headers live in a separate tree under a sibling include/ directory. Based on advice from the Internet, I am trying to do out-of-source builds, with the debug flavor in a debug/ sibling directory, and release in release/ This all works from the command line, but I am using Eclipse CDT as my primary IDE and would like to get decent integration between that and CMake. When I use CMake's Eclipse generator and then import the project into Eclipse, there are some serious issues. The primary issue is that when I hit Ctrl+Shift+R to bring up the Open Resource dialog and then type in the name of a source file, I get 3 results: one under each of [Source files], [Subprojects], and [Targets]. This is awful, especially since picking the wrong one results in weird behavior like inability to resolve include directives or inability to toggle between source and corresponding header file. Is there some way to address this without resulting to in-source builds? I'm even willing to butcher the project files post-generate using Python if it would help. Thanks, - Ben S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrosso at lbl.gov Tue Apr 2 19:58:56 2019 From: mrosso at lbl.gov (Michele Rosso) Date: Tue, 2 Apr 2019 16:58:56 -0700 Subject: [CMake] Possible inconsistent behavior in target_sources() and CMake 3.14 Message-ID: Hello, according to the doc for CMake 3.14, target_sources() interprets relative source file paths as being relative to the current source directory, i.e. it should prepend CMAKE_CURRENT_SOURCE_DIR to the relative paths given by the user. However, this is not the case if the target and the sources are defined in the same directory. I attached a simple example to reproduce the issue. The structure of the example is as follows: - cmake-bug/ - CMakeLists.txt - main.cpp - foo/ - CMakeLists.txt - foo.H - foo.cpp - bar/ - CMakeLists.txt - bar.H - bar.cpp Target "main.exe" is defined in the top-level CMakeLists.txt, while its headers and sources are located in the the top-level directory and in the sub-directories 'foo' and 'bar'. After target_sources is used to include all the headers and sources, I retrieve the "SOURCES" property for `main.exe`: all the sources and headers but `main.cpp` are given the correct (absolute) path. Is this the intended behavior? If so, why should a source file located in the same directory where the target is defined be treated any differently? Thanks, Michele -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-bug.tar.gz Type: application/gzip Size: 829 bytes Desc: not available URL: From zbeekman at gmail.com Wed Apr 3 09:24:12 2019 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 3 Apr 2019 09:24:12 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice In-Reply-To: References: Message-ID: Hi all, This didn't get any bites, so I'm re-sending it. Any thoughts, however short they may be would be appreciated. Right now, the only obvious solution to me is to use `install(SCRIPT ...)` where a script uses `file(GLOB_RECURSE ...)` to enumerate modules and submodules in the build path, followed by a `foreach(...)` loop over all the found artifacts to install them with `file(INSTALL ...)`. This feels fragile, and un-idiomatic. Am I missing a better way to do this? Thanks, Zaak On Sun, Mar 31, 2019 at 5:10 PM Zaak Beekman wrote: > > Hi all, > > What's the best approach for handling cross-platform (i.e., MSVS, Mac, > Linux) installation of Fortran module files associated with > libraries? > > After searching the docs, I couldn't find any good and obvious way to > handle installation of Fortran module files associated with library > targets. These are compiler specific, and, perhaps a better approach > might be to ship all executable code compiled into libraries and put > inside submodules, and ship a free/open parent module with interface, > type, class, constant, etc. definitions. > > But, at any rate, it would be nice if there were a better way to > install Fortran module files besides something like: > > ``` > set(CMAKE_Fortran_MODULE_DIRECTORY "${CMAKE_BINARY_DIR}/include") > > ... > > install(DIRECTORY ${CMAKE_Fortran_MODULE_DIRECTORY} DESTINATION > ${CMAKE_INSTALL_INCLUDE_DIR}) > ``` > > In particular, it is hard to know which .mod and .smod files will be > produced ahead of time without parsing the source, or manually > enumerating them. One can use the approach outlined above, but a few > problems and drawbacks remain: > > 1. With IDEs like MSVS, I always seem to end up getting an additional > directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name > of the build configuration (e.g., `debug`) > 2. Utility/test modules may have generic names (e.g. assertions.mod) > that probably should not get installed and will very likely lead to > name clashes with consuming projects > 3. Lack of standard definition of module file format and Fortran ABI > makes portability dicey, at least until ISO_Fortran_BINDING is widely > available and adopted > > It would be great if there were a target property that could be > queried for associated module and submodule files. In addition > additional "it just works" logic around installing Fortran targets and > how modules are handled would be really nice. This obviously isn't an > easy/trivial question to answer, but being able to query targets for > module file build artifacts would be a great starting point. > > In the mean time, I think my only acceptable options to handle IDEs > like MSVS is to use the `SCRIPT` signature of `install()` where I can > use `file(GLOB_RECURSE ...)` to find module files and strip out any > build configuration specific directory structure. (Or at least adopt > my own logic and conventions for this...) > > Any tips or advice would be very appreciated! > > Thanks, > Zaak From brad.king at kitware.com Wed Apr 3 09:35:59 2019 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Apr 2019 09:35:59 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice In-Reply-To: References: Message-ID: On 3/31/19 5:10 PM, Zaak Beekman wrote: > What's the best approach for handling cross-platform (i.e., MSVS, Mac, > Linux) installation of Fortran module files associated with > libraries? The `install(DIRECTORY)` approach is the current recommendation. > problems and drawbacks remain: > > 1. With IDEs like MSVS, I always seem to end up getting an additional > directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name > of the build configuration (e.g., `debug`) Do those directories contain the `.mod` files or are they extra? In the latter case, use `install(DIRECTORY)`'s options for excluding content by pattern or regex. > 2. Utility/test modules may have generic names (e.g. assertions.mod) > that probably should not get installed and will very likely lead to > name clashes with consuming projects Set the per-target Fortran_MODULE_DIRECTORY property to keep private modules out of the installed directory. > 3. Lack of standard definition of module file format and Fortran ABI > makes portability dicey, at least until ISO_Fortran_BINDING is widely > available and adopted That seems orthogonal. It's a reason to not install them at all. > It would be great if there were a target property that could be > queried for associated module and submodule files. We don't have that information at CMake time. The set of files is not discovered until the build, and there is no one place that has the full set. -Brad From zbeekman at gmail.com Wed Apr 3 10:09:57 2019 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 3 Apr 2019 10:09:57 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice In-Reply-To: References: Message-ID: Thanks so much Brad! On Wed, Apr 3, 2019 at 9:35 AM Brad King wrote: > The `install(DIRECTORY)` approach is the current recommendation. OK > Do those directories contain the `.mod` files or are they extra? > In the latter case, use `install(DIRECTORY)`'s options for excluding > content by pattern or regex. They contain the mod files. I didn't ask for a $ directory to be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's there, and all the .mod files are inside it, so `install(DIRECTORY ...)` is incapable (at least in my testing) of fetching them out of the $ subdirectory. > Set the per-target Fortran_MODULE_DIRECTORY property to keep private > modules out of the installed directory. That's the plan. > We don't have that information at CMake time. The set of files is > not discovered until the build, and there is no one place that has > the full set. Hmmmm ok, thanks for the info. Fortran, always making tooling hard... Well thank you SO MUCH once again for the response. Best, Zaak From brad.king at kitware.com Wed Apr 3 10:27:13 2019 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Apr 2019 10:27:13 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice In-Reply-To: References: Message-ID: <4b0809fc-81b9-bd2a-bddf-9c757f2afb40@kitware.com> On 4/3/19 10:09 AM, Zaak Beekman wrote: > They contain the mod files. I didn't ask for a $ directory to > be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's > there, and all the .mod files are inside it, so `install(DIRECTORY > ...)` is incapable (at least in my testing) of fetching them out of > the $ subdirectory. The VS generator supports multiple separate configurations being built under the same build tree, so all artifacts such as object files, libraries, executables, and Fortran modules need to have a per-config location. For libraries and executables we already have ways for projects to specify per-config locations such that no per-config subdirectory is added. I've opened an issue to do the same for Fortran modules: https://gitlab.kitware.com/cmake/cmake/issues/19126 Meanwhile you may be able to use `$` in the source directory specified by `install(DIRECTORY)` when CMAKE_GENERATOR is a Visual Studio generator. -Brad From zbeekman at gmail.com Wed Apr 3 12:16:09 2019 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 3 Apr 2019 12:16:09 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice In-Reply-To: <4b0809fc-81b9-bd2a-bddf-9c757f2afb40@kitware.com> References: <4b0809fc-81b9-bd2a-bddf-9c757f2afb40@kitware.com> Message-ID: Awesome, thanks! On Wed, Apr 3, 2019 at 10:26 AM Brad King wrote: > On 4/3/19 10:09 AM, Zaak Beekman wrote: > > They contain the mod files. I didn't ask for a $ directory to > > be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's > > there, and all the .mod files are inside it, so `install(DIRECTORY > > ...)` is incapable (at least in my testing) of fetching them out of > > the $ subdirectory. > > The VS generator supports multiple separate configurations being > built under the same build tree, so all artifacts such as object > files, libraries, executables, and Fortran modules need to have > a per-config location. > > For libraries and executables we already have ways for projects > to specify per-config locations such that no per-config > subdirectory is added. I've opened an issue to do the same for > Fortran modules: > > https://gitlab.kitware.com/cmake/cmake/issues/19126 > > Meanwhile you may be able to use `$` in the source directory > specified by `install(DIRECTORY)` when CMAKE_GENERATOR is a > Visual Studio generator. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Wed Apr 3 12:44:04 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 3 Apr 2019 09:44:04 -0700 Subject: [CMake] Eclipse generator question In-Reply-To: References: Message-ID: Update - I think I found a tolerable workaround: If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and then inject a link to my include directory into the .project file, things work a lot better: - I get only one copy of each source file in the Open Resource dialog. - I get source and header files in the Open Resource dialog. - I can toggle between source and header. - I can build from Eclipse. - I get version control support, even in my include tree. - Indexing is fast. It seems that Eclipse improved version control support quite a bit since the CMake Eclipse generator was last touched. Unfortunately this seems to also mean that a lot of the linked resources that CMake generates by default now just add noise (hence my better results from turning them off). There are still some aspects that are not ideal. In particular, CMake brings the source files into the project via the "[Source directory]" virtual folder, which just points to the CMake project root directory on the filesystem. This approach has a number of issues: - Source files that are not part of the CMake project show up in Open Resource and possibly the Eclipse CDT index. - A view of the sources/headers belonging to each CMake target is not really provided (although you can glean the sources part somewhat by looking at the detailed target tree). On Tue, Apr 2, 2019 at 9:04 AM Benjamin Shadwick wrote: > I've recently converted a complex C++ codebase to CMake. I'm stuck using > 2.8.12.2. > > The codebase has a source tree, whose leaf directories each build a shared > library or an executable binary. The source lives in src/ while the headers > live in a separate tree under a sibling include/ directory. > > Based on advice from the Internet, I am trying to do out-of-source builds, > with the debug flavor in a debug/ sibling directory, and release in release/ > > This all works from the command line, but I am using Eclipse CDT as my > primary IDE and would like to get decent integration between that and CMake. > > When I use CMake's Eclipse generator and then import the project into > Eclipse, there are some serious issues. The primary issue is that when I > hit Ctrl+Shift+R to bring up the Open Resource dialog and then type in the > name of a source file, I get 3 results: one under each of [Source files], > [Subprojects], and [Targets]. This is awful, especially since picking the > wrong one results in weird behavior like inability to resolve include > directives or inability to toggle between source and corresponding header > file. > > Is there some way to address this without resulting to in-source builds? > I'm even willing to butcher the project files post-generate using Python if > it would help. > > Thanks, > - Ben S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Wed Apr 3 16:01:49 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 03 Apr 2019 22:01:49 +0200 Subject: [CMake] Eclipse generator question In-Reply-To: References: Message-ID: <4936818.EevZM8MSgL@linux> Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > Update - I think I found a tolerable workaround: > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > then inject a link to my include directory into the .project file, things > work a lot better: > - I get only one copy of each source file in the Open Resource dialog. > - I get source and header files in the Open Resource dialog. > - I can toggle between source and header. > - I can build from Eclipse. > - I get version control support, even in my include tree. > - Indexing is fast. > > It seems that Eclipse improved version control support quite a bit since > the CMake Eclipse generator was last touched. Unfortunately this seems to > also mean that a lot of the linked resources that CMake generates by > default now just add noise (hence my better results from turning them off). Newer versions of CDT (9.1+) seem to have trouble to properly read the .cproject file generated by cmake [1] [2]. Forget about running cmake manually and install _cmake4eclipse_ from the eclipse marketplace. It runs cmake automatically [3] and comes with support for the eclipse indexer. Some people even use it for CUDA in the nvidia insight IDE. (Disclaimer: I am the maintainer) Just try it with one of the example projects [4]. Martin [1] [2] [3] https://github.com/15knots/cmake4eclipse#design-goals [4] https://github.com/15knots/cmake4eclipse-sample-projects -- Cd wrttn wtht vwls s mch trsr. From senorblanco at chromium.org Wed Apr 3 16:06:02 2019 From: senorblanco at chromium.org (Stephen White) Date: Wed, 3 Apr 2019 16:06:02 -0400 Subject: [CMake] Android NDK --gcc-toolchain issue with Clang Message-ID: Hi there, Apologies in advance if this is not the correct mailing list. I'm working on a C++ project which has existing CMake files and works on Linux and Mac. I was attempting to build it on the Android NDK cross-compiling to ARM64, and ran into an issue. In particular, the toolchain determination for test compilation fails as follows: $HOME/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --target=aarch64-none-linux-android --gcc-toolchain=$HOME/Android/Sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64 --sysroot=$HOME/Android/Sdk/ndk-bundle/platforms/android-28/arch-arm64 -funwind-tables -no-canonical-prefixes -D__ANDROID_API__=28 -fexceptions -g -fPIE -pie -Wl,--gc-sections CMakeFiles/cmTC_34db0.dir/testCCompiler.c.o -o cmTC_34db0 /usr/bin/ld: unrecognised emulation mode: aarch64linux The problem seems to be where --gcc-toolchain is set to: $HOME/Android/Sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64 (note the double slash). On my installation of the NDK (r19c, Linux), the toolchain seems to be in: $HOME/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/ My android.toolchain.cmake file is as follows: set(CMAKE_SYSTEM_NAME Android) set(CMAKE_ANDROID_NDK $ENV{HOME}/Android/Sdk/ndk-bundle) set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) set(CMAKE_ANDROID_ARCH_ABI arm64-v8a) set(CMAKE_ANDROID_STL_TYPE c++_shared) I was able to get it to work by applying the small patch below: diff --git a/Modules/Platform/Android/Determine-Compiler-NDK.cmake b/Modules/Platform/Android/Determine-Compiler-NDK.cmake index 5f2cc524e5..c211bbceee 100644 --- a/Modules/Platform/Android/Determine-Compiler-NDK.cmake +++ b/Modules/Platform/Android/Determine-Compiler-NDK.cmake @@ -239,7 +239,7 @@ set(_ANDROID_TOOL_CXX_TOOLCHAIN_SUFFIX "${_ANDROID_TOOL_C_TOOLCHAIN_SUFFIX}") if(_ANDROID_TOOL_CLANG_NAME) message(STATUS "Android: Selected Clang toolchain '${_ANDROID_TOOL_CLANG_NAME}' with GCC toolchain '${_ANDROID_TOOL_NAME}'") set(_ANDROID_TOOL_C_COMPILER "${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR}/bin/clang${_ANDROID_HOST_EXT}") - set(_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN ${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_NAME}/prebuilt/${_ANDROID_HOST_DIR}) + set(_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN ${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR}) set(_ANDROID_TOOL_CXX_COMPILER "${CMAKE_ANDROID_NDK}/toolchains/${_ANDROID_TOOL_LLVM_NAME}/prebuilt/${_ANDROID_HOST_DIR}/bin/clang++${_ANDROID_HOST_EXT}") set(_ANDROID_TOOL_CXX_COMPILER_EXTERNAL_TOOLCHAIN "${_ANDROID_TOOL_C_COMPILER_EXTERNAL_TOOLCHAIN}") else() The reason seems to be that if ANDROID_TOOL_NAME contains -clang, it is set to the empty string on line 120 (CMake 10.13), so the external toolchain path contains an empty directory element (//). ANDROID_TOOL_LLVM_NAME contains "llvm", which is the correct string to make the above path correct on my installation. If I'm doing something wrong and there's a better way to do this which doesn't require patching CMake, please let me know. Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Wed Apr 3 16:26:59 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 3 Apr 2019 13:26:59 -0700 Subject: [CMake] Eclipse generator question In-Reply-To: <4936818.EevZM8MSgL@linux> References: <4936818.EevZM8MSgL@linux> Message-ID: I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking of the Eclipse project after you create it, and I'm pretty sure it suffers from the same problem of leaving you with an Eclipse project whose source tree reflects what is in the filesystem rather than what is defined in the CMake project. It's really annoying that I spent all this time building a CMake project for a complex codebase, only to have the IDE present and index the entire source tree on the filesystem instead of the subset that is actually being built by the CMake configuration. I should probably enhance my project-tweaking python script to add filters to the generated Eclipse project to hide anything that isn't in the CMake project. On Wed, Apr 3, 2019 at 1:02 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > > Update - I think I found a tolerable workaround: > > > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > > then inject a link to my include directory into the .project file, things > > work a lot better: > > - I get only one copy of each source file in the Open Resource dialog. > > - I get source and header files in the Open Resource dialog. > > - I can toggle between source and header. > > - I can build from Eclipse. > > - I get version control support, even in my include tree. > > - Indexing is fast. > > > > It seems that Eclipse improved version control support quite a bit since > > the CMake Eclipse generator was last touched. Unfortunately this seems to > > also mean that a lot of the linked resources that CMake generates by > > default now just add noise (hence my better results from turning them > off). > > Newer versions of CDT (9.1+) seem to have trouble to properly read the > .cproject file generated by cmake [1] [2]. > > Forget about running cmake manually and install _cmake4eclipse_ from the > eclipse marketplace. It runs cmake automatically [3] and comes with > support > for the eclipse indexer. Some people even use it for CUDA in the nvidia > insight IDE. (Disclaimer: I am the maintainer) > Just try it with one of the example projects [4]. > > Martin > > [1] > [2] t=msg&th=1094239&goto=1797891&#msg_1797891> > [3] https://github.com/15knots/cmake4eclipse#design-goals > [4] https://github.com/15knots/cmake4eclipse-sample-projects > > > -- > Cd wrttn wtht vwls s mch trsr. > > > > > -- > > 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 fifteenknots505 at gmail.com Wed Apr 3 16:32:39 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 03 Apr 2019 22:32:39 +0200 Subject: [CMake] Eclipse generator question In-Reply-To: References: Message-ID: <2305165.9ylri24IXc@linux> Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > Update - I think I found a tolerable workaround: > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > then inject a link to my include directory into the .project file, things > work a lot better: You (and other having problems with eclipse projects generated by cmake) might want to read these posts of the CDT project lead concerning cmake's CDT4 generator [1] [2]. Martin [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c3 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c5 -- Cd wrttn wtht vwls s mch trsr. From benshadwick at gmail.com Wed Apr 3 16:55:45 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 3 Apr 2019 13:55:45 -0700 Subject: [CMake] Eclipse generator question In-Reply-To: <2305165.9ylri24IXc@linux> References: <2305165.9ylri24IXc@linux> Message-ID: FYI, I opened a bug on CMake's tracker about updating the CMake generator since its outputs are kind of garbage for modern CDT releases: https://gitlab.kitware.com/cmake/cmake/issues/19107 Unfortunately the only feedback I got was that there is a push to remove *all* generators in favor of forcing IDEs to use cmake-file-api. I opened a bug on the Eclipse tracker asking if they knew about this push and whether anyone was working on it from the CDT end, and they aren't but are receptive: https://bugs.eclipse.org/bugs/show_bug.cgi?id=545905 None of that helps me, though, because I'm stuck on CMake 2.8.12.2 for now. I think my main philosophical issue is that CMake lets you define a project, and I'd like to see that definition reflected in Eclipse. Unfortunately, both the CMake Eclipse generator and cmake4eclipse plugin leave you with a filesystem-oriented view of the source instead of a CMake project oriented view. You can get most of this from importing a CMake project into something more primitive like NetBeans. Maybe being tied to the filesystem view is an inherent limitation of Eclipse (and/or CDT), or maybe it was at one time and neither CMake nor cmake4eclipse are taking advantage of what modern Eclipse versions can do. On Wed, Apr 3, 2019 at 1:32 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick: > > Update - I think I found a tolerable workaround: > > > > If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and > > then inject a link to my include directory into the .project file, things > > work a lot better: > > You (and other having problems with eclipse projects generated by cmake) > might > want to read these posts of the CDT project lead concerning cmake's CDT4 > generator [1] [2]. > > Martin > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c3 > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530090#c5 > > > -- > Cd wrttn wtht vwls s mch trsr. > > > > > -- > > 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 fifteenknots505 at gmail.com Wed Apr 3 17:18:42 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 03 Apr 2019 23:18:42 +0200 Subject: [CMake] Eclipse generator question In-Reply-To: References: <4936818.EevZM8MSgL@linux> Message-ID: <1907275.WsIYnJSqm2@linux> Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick: > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking Really? Just set _CMake Builder (portable)_ as the current builder and build. > of the Eclipse project after you create it, and I'm pretty sure it suffers > from the same problem of leaving you with an Eclipse project whose source > tree reflects what is in the filesystem rather than what is defined in the > CMake project. What does that mean: _an Eclipse project whose source tree reflects what is in the filesystem rather than what is defined in the CMake project._ ?? > It's really annoying that I spent all this time building a CMake project > for a complex codebase, only to have the IDE present and index the entire > source tree on the filesystem instead of the subset that is actually being > built by the CMake configuration. If the IDE indexing all source files takes too long, I would say it is a problem with the IDE; but not a problem of cmake's IDE project generator (as the topic states). > I should probably enhance my project-tweaking python script to add filters > to the generated Eclipse project to hide anything that isn't in the CMake > project. That's the only way to go in your case. How should the CDT4 project generator know about all your source files that do not take part in a build? From fifteenknots505 at gmail.com Wed Apr 3 17:50:02 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 03 Apr 2019 23:50:02 +0200 Subject: [CMake] Eclipse generator question In-Reply-To: References: <2305165.9ylri24IXc@linux> Message-ID: <8270167.GBGhDueiMi@linux> Am Mittwoch, 3. April 2019, 22:55:45 CEST schrieb Benjamin Shadwick: > FYI, > > I opened a bug on CMake's tracker about updating the CMake generator since > its outputs are kind of garbage for modern CDT releases: > https://gitlab.kitware.com/cmake/cmake/issues/19107 > > Unfortunately the only feedback I got was that there is a push to remove > *all* generators in favor of forcing IDEs to use cmake-file-api. I opened a +1 from me for removing IDE project generators. [...] > Maybe being tied to the filesystem view is an inherent limitation of > Eclipse (and/or CDT), or maybe it was at one time and neither CMake nor To implement the 'index only files referenced through the build script' view, *any* IDE would have to *interpret* the build scripts. Just choose an IDE that has a build script interpreter to solve your use case. > cmake4eclipse are taking advantage of what modern Eclipse versions can do. Sounds promising. What is it that _modern Eclipse versions can do_? -- Cd wrttn wtht vwls s mch trsr. From benshadwick at gmail.com Wed Apr 3 17:53:59 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 3 Apr 2019 14:53:59 -0700 Subject: [CMake] Fwd: Eclipse generator question In-Reply-To: References: <4936818.EevZM8MSgL@linux> <1907275.WsIYnJSqm2@linux> Message-ID: Oops, meant to send this to the mailing list, but GMail keeps trying to divert me. ---------- Forwarded message --------- From: Benjamin Shadwick Date: Wed, Apr 3, 2019 at 2:52 PM Subject: Re: [CMake] Eclipse generator question To: Martin Weber On Wed, Apr 3, 2019 at 2:18 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick: > > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of > tweaking > > Really? Just set _CMake Builder (portable)_ as the current builder and > build. > It required a lot more tweaking than that for an out of source build, including manually enabling the CMAKE includes and defines providers. > > of the Eclipse project after you create it, and I'm pretty sure it > suffers > > from the same problem of leaving you with an Eclipse project whose source > > tree reflects what is in the filesystem rather than what is defined in > the > > CMake project. > > What does that mean: _an Eclipse project whose source tree reflects what > is in > the filesystem rather than what is defined in the CMake project._ ?? > This is exactly what I'm getting at: People have marinated so much in the way Eclipse works by default that what I'm saying sounds like a non sequitur. I'll try to explain: - I have a repository with a large source tree that contains hundreds of leaf directories. - Each leaf directory contains source that needs to be built into a shared library or an executable binary. - The source tree contains a superset of the functionality that is needed by all configurations. - Any particular configuration of the CMake project will result in only a subset of the libraries and/or binaries being built. - The subset being built is defined via CMake option() commands that set (or don't) cache variables that control which subdirectories are added to the CMake project. What I want from Eclipse: - Only show in the project tree and Open Resource dialog the subset of source files that belong to the current configuration of the CMake project, so that developers don't get confused about what is relevant or not to the configuration of CMake they are working in. - Only index the subset of source files that belong to the current configuration of the CMake project, so that resources are not wasted indexing irrelevant sources, and so that developers are not flooded with irrelevant indexer errors. - Show header files that are assigned to a target, including custom header-only targets ("custom_target(... SOURCES)"), as is done by other IDEs. > If the IDE indexing all source files takes too long, I would say it is a > problem with the IDE; but not a problem of cmake's IDE project generator > (as > the topic states). > Time is only one aspect (see above), although it's particularly bad with the out-of-box Eclipse project generated by CMake's default settings because it indexes every source file 3 times. > That's the only way to go in your case. How should the CDT4 project > generator > know about all your source files that do not take part in a build? > The point I'm trying to make is that I *don't* want Eclipse to know about source files that are *not* being built, but it *does* know about them because all solutions (CMake generator, cmake4eclipse) just point Eclipse at the source tree *in the filesystem*, and not at the conceptual project tree defined via the CMakeLists.txt hierarchy. Remember that for me, the filesystem contains lots of sources that are *not* relevant to any one CMake configuration that developers will be working with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Wed Apr 3 18:02:06 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 3 Apr 2019 15:02:06 -0700 Subject: [CMake] Eclipse generator question In-Reply-To: <8270167.GBGhDueiMi@linux> References: <2305165.9ylri24IXc@linux> <8270167.GBGhDueiMi@linux> Message-ID: On Wed, Apr 3, 2019 at 2:50 PM Martin Weber wrote: > To implement the 'index only files referenced through the build script' > view, > *any* IDE would have to *interpret* the build scripts. > Just choose an IDE that has a build script interpreter to solve your use > case. > Qt Creator and Visual Studio Code (with the appropriate plugins installed) seem to be able to do this. I now use them at home in preference over Eclipse CDT because of this, but Eclipse CDT is currently the path of least resistance at work. > > cmake4eclipse are taking advantage of what modern Eclipse versions can > do. > > Sounds promising. What is it that _modern Eclipse versions can do_? > It looks like you can compose the Eclipse project tree to look any way you want via use of linked resources. Apparently when doing this in older versions of Eclipse, it would break its version control integration. This no longer seems to be the case. When using the CMake Eclipse project generator via its default settings, I get a "[Targets]" virtual directory in the Eclipse project that actually shows the source files under their respective targets, in a structure that is closer to that defined in the CMake project than what is on the filesystem. Unfortunately it also generates a bunch of *other* garbage to make things work in older Eclipse releases that just create a bunch of noise in new releases that make the project almost unusable for anything but building. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Cook at riotinto.com Wed Apr 3 21:42:21 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Thu, 4 Apr 2019 01:42:21 +0000 Subject: [CMake] CPack/WiX shortcuts with custom arguments Message-ID: To follow up on this, I tried creating a .bat file to run my program with the required command line arguments, but I was unable to add a shortcut to the .bat file because cmake appends ".exe" to the name of the executable in CPACK_PACKAGE_EXECUTABLES. I think the only way to make it work is to create an executable that doesn't require command line parameters. Steve From: Cook, Steven (G&I) Sent: Friday, 22 March 2019 11:17 AM To: 'cmake at cmake.org' Subject: CPack/WiX shortcuts with custom arguments Hi, I'm attempting to transition from NSIS to WiX for our Windows installer and have been unable to find a way to create customised shortcuts with WiX (I would like to specify both the working directory and command line parameters). Some approaches I've tried are: * Specifying CPACK_PACKAGE_EXECUTABLES, and then using CPACK_WIX_PATCH_FILE to modify the shortcut. This approach doesn't work because the patching mechanism can only add new XML tags; it is unable to add or modify properties on existing tags. * Creating the shortcut myself via CPACK_WIX_EXTRA_SOURCES. This doesn't work because PROGRAM_MENU_FOLDER is not defined in directories.wxs unless cpack is creating shortcuts itself. And I can't define this directory myself because the patching mechanism doesn't allow modifications to the top level TARGETDIR directory. Ideas of things that might work but which are not ideal: * Create an unwanted shortcut with cpack and then define my own shortcuts with CPACK_WIX_EXTRA_SOURCES. But then there is an unwanted shortcut. * Create separate .bat files for each start menu item so that working directory and command line parameters are not required. Is there anything else I can try? Thanks Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Thu Apr 4 01:56:20 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Thu, 4 Apr 2019 06:56:20 +0100 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: Hello again, no ideas so far? Perhaps I can elaborate. I have tried multiple approaches over the years. Most recently adding the source files of the lib explicitly as dependencies to the created executable. Like this: set (SRC MySource1.cpp MySource2.cpp ) set (HDR MySource1.hpp MySource2.hpp ) add_library(mylib STATIC ${SRC} ${HDR}) add_executable(myexecutable main.cpp) target_link_libraries(myexecutable mylib ) add_dependencies(myexecutable ${SRC}) This leads to errors though: CMake Error at CMakeLists.txt:79 (add_dependencies): The dependency target "MySource1.cpp" of target "myexecutable" does not exist. Obviously, I cannot simply state a filename and treat it as a target. I have however seen something similar been done when it comes to code generation. I have also seen explicit subtargets for files being created and then depend on those subtargets. But I don't really know how to do this the right way. Alternatively I would also appreciate input about what exactly the problem with depending on static libs is. The explanations I remember from my last efforts to tackle this weren't really satisfying. If I understood in more detail why this isn't possible I may be able to better craft a workaround on my own. Really, anything helps. I am losing time and nerve every day because of this and have been paying this price for so many years that I think it really is time to come up with a solution. Cheers, Stephan On Tue, Apr 2, 2019 at 5:54 AM Stephan Menzel wrote: > Hello List, > > In our projects we are using static linkage on Windows (MSVC) and Linux. A > number of static libs are created and then linked into executables, such as > unit tests, tools and the actual production artifacts. Very normal stuff. > > add_library(mylib STATIC mysources) > add_excecutable(mytest mytest.cpp) > target_link_libraries(mytest mylib) > > Now although I don't understand the exact reasons behind that, over the > years came to accept that depedencies between the lib and the resulting > artifcats are not working. Like, when I change a source file to mylib, the > lib will get rebuilt but the resulting test tool won't be relinked. > For test driven development or busy change cycles that can put quite a > strain on effort, especially on windows. My normal workflow is that I > always click in mytest.cpp, add and remove a space to mark it dirty as > quickly as possible and thereby cause the rebuild. But sometimes I forget > this and this caused me quite a bit of extra work. > My question is, can I fake that dependency somehow? Perhaps by some hack > or using some workaround? > > What I want to achieve is that when I change the lib, the unit test (or > any other test tool using it) that depends on it will be relinked, even if > it has not changed. > > Is that possible somehow? > > Cheers, > Stephan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeenai at fb.com Thu Apr 4 02:13:36 2019 From: smeenai at fb.com (Shoaib Meenai) Date: Thu, 4 Apr 2019 06:13:36 +0000 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: Could you share more details about your CMake version, the platform you're on, and the generator you're using? I haven't run into this issue (and it's pretty counter to how I'd expect CMake to behave). The only similar setting I'm aware of is https://cmake.org/cmake/help/latest/prop_tgt/LINK_DEPENDS_NO_SHARED.html, but that's for shared libraries, not static libraries. As an experiment, I used the following CMakeLists.txt: cmake_minimum_required(VERSION 3.4.3) project(cmtest C) add_library(mylib STATIC source.c) add_executable(mytest test.c) target_link_libraries(mytest mylib) I'm running CMake 3.12.3 on macOS 10.14.1, and I tried both the Makefile and Ninja generators. With both, any modification to source.c causes mytest to be rebuilt, as I'd expect (and unlike what you're seeing). If you're able to provide a small self-contained CMakeLists.txt that reproduces the issue, that'd also be helpful for debugging. Thanks, Shoaib Meenai From: CMake on behalf of Stephan Menzel Date: Wednesday, April 3, 2019 at 10:56 PM To: cmake Subject: Re: [CMake] Fake dependencies of executables to static libs Hello again, no ideas so far? Perhaps I can elaborate. I have tried multiple approaches over the years. Most recently adding the source files of the lib explicitly as dependencies to the created executable. Like this: set (SRC MySource1.cpp MySource2.cpp ) set (HDR MySource1.hpp MySource2.hpp ) add_library(mylib STATIC ${SRC} ${HDR}) add_executable(myexecutable main.cpp) target_link_libraries(myexecutable mylib ) add_dependencies(myexecutable ${SRC}) This leads to errors though: CMake Error at CMakeLists.txt:79 (add_dependencies): The dependency target "MySource1.cpp" of target "myexecutable" does not exist. Obviously, I cannot simply state a filename and treat it as a target. I have however seen something similar been done when it comes to code generation. I have also seen explicit subtargets for files being created and then depend on those subtargets. But I don't really know how to do this the right way. Alternatively I would also appreciate input about what exactly the problem with depending on static libs is. The explanations I remember from my last efforts to tackle this weren't really satisfying. If I understood in more detail why this isn't possible I may be able to better craft a workaround on my own. Really, anything helps. I am losing time and nerve every day because of this and have been paying this price for so many years that I think it really is time to come up with a solution. Cheers, Stephan On Tue, Apr 2, 2019 at 5:54 AM Stephan Menzel > wrote: Hello List, In our projects we are using static linkage on Windows (MSVC) and Linux. A number of static libs are created and then linked into executables, such as unit tests, tools and the actual production artifacts. Very normal stuff. add_library(mylib STATIC mysources) add_excecutable(mytest mytest.cpp) target_link_libraries(mytest mylib) Now although I don't understand the exact reasons behind that, over the years came to accept that depedencies between the lib and the resulting artifcats are not working. Like, when I change a source file to mylib, the lib will get rebuilt but the resulting test tool won't be relinked. For test driven development or busy change cycles that can put quite a strain on effort, especially on windows. My normal workflow is that I always click in mytest.cpp, add and remove a space to mark it dirty as quickly as possible and thereby cause the rebuild. But sometimes I forget this and this caused me quite a bit of extra work. My question is, can I fake that dependency somehow? Perhaps by some hack or using some workaround? What I want to achieve is that when I change the lib, the unit test (or any other test tool using it) that depends on it will be relinked, even if it has not changed. Is that possible somehow? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Thu Apr 4 02:13:15 2019 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 04 Apr 2019 02:13:15 -0400 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: On Thu, 2019-04-04 at 06:56 +0100, Stephan Menzel wrote: > add_library(mylib STATIC mysources) > add_excecutable(mytest mytest.cpp) > target_link_libraries(mytest mylib) > > Now although I don't understand the exact reasons behind that, over > the years came to accept that depedencies between the lib and the > resulting artifcats are not working. Like, when I change a source > file to mylib, the lib will get rebuilt but the resulting test tool > won't be relinked. This is definitely not true, as stated. I feel like I must be missing something about your stated environment because this is really basic, fundamental CMake behavior, which has always worked. If in your environment you are not seeing executables rebuilt when libraries they depend on are updated, then there is something more complex about it than the straightforward case you provide above. Rather than try to find a workaround it would be better to find the root cause. If you can provide a sample setup that behaves as you describe perhaps we could explain what's happening. Also please let us know which version of CMake you're using. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Thu Apr 4 03:16:54 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Thu, 4 Apr 2019 08:16:54 +0100 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: Hello Paul and Shoaib, I'm answering to the both of you. On Thu, Apr 4, 2019 at 7:13 AM Paul Smith wrote: > Now although I don't understand the exact reasons behind that, over the > years came to accept that depedencies between the lib and the resulting > artifcats are not working. Like, when I change a source file to mylib, the > lib will get rebuilt but the resulting test tool won't be relinked. > > > This is definitely not true, as stated. I feel like I must be missing > something about your stated environment because this is really basic, > fundamental CMake behavior, which has always worked. > First of all, thanks for the information. I was not aware that this is supposed to work. As I said, I've been struggling with this issue for years now and I recall posting this to this list too but the only explanation I ever found was something along the lines of "dependencies would exist to objects inside the lib, not the lib as it is a static archive". But I'm pulling this out of my 'memory' now, nothing to rely on. All I remembered is that this is not supposed to work. But now you say the opposite, which gives me a little hope. > If in your environment you are not seeing executables rebuilt when > libraries they depend on are updated, then there is something more complex > about it than the straightforward case you provide above. > I have seen this in two major projects I have been working on in the last years. Both were Linux and Windows, MSVC 14 and 15 on Windows. And I do believe the issue is on Windows. I am not sure which CMake version I have seen this first on. Let's make it 3.10.x cause this was when I posted this to the list last time but by then I was already having the problem for a longer time. Today I am using CMake version 3.13.2 but I have been using many different versions up to this one. Both projects were large but not huge, having about 10 - 15 targets plus additional 50 unit tests plus another 5 test tools. Unfortunately I cannot publish the projects themselves but one that I currently see the issue with is mredis (https://github.com/MrMoose/mredis) which, among others, is pulled in as a submodule. C++ only, some protobuf code generation is involved but not in the targets that I'm talking about. Since the issue has been persisting for so long now, the projects and CMakeLists have substantially changed many times, so it's really hard to come up with something I would consider 'strange' or 'different' as a possible explanation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kerstin.s.keller at gmail.com Thu Apr 4 07:24:52 2019 From: kerstin.s.keller at gmail.com (Kerstin Keller) Date: Thu, 4 Apr 2019 13:24:52 +0200 Subject: [CMake] dll artifacts - Runtime or Library Output Message-ID: On Windows, a .dll is considered by CMake to be a "RUNTIME" Output artifact if it was added with the `add_library(my_liib SHARED my_lib.cpp), however if it was added with the MODULE keyword, it is considered to be a "LIBRARY" output, as stated in the documentation https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#runtime-output-artifacts I just discovered this behavior and it seems quite unintuitive to me. If I dynamically load a library with LoadLibrary without specying an absolute path, Windows will still use the default search path logic for Windows, which means first same directory as the executable loading the module, e.g. the RUNTIME output directory. (See also https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya ) Can you please elaborate on this? Thanks, Kerstin -------------- next part -------------- An HTML attachment was scrubbed... URL: From borgogozo at antidot.net Thu Apr 4 08:31:11 2019 From: borgogozo at antidot.net (Benjamin Orgogozo) Date: Thu, 4 Apr 2019 14:31:11 +0200 Subject: [CMake] Remove compilation flags for a given target Message-ID: <20190404123111.GA11793@drus> Hello, in our code base we would like to add a warning compilation flags. Nevertheless, this flag prevents us from compiling a few targets so we would like to remove this flag for the given targets. If I'm right (I'm far from being a cmake expert) there are two ways to define "global" compilation flags: 1- set the CXX_COMPILE_FLAGS variable; 2- use add_compile_options($<$:-WMyFavouriteWarning). Since I don't want to *add* a compilation flags but remove one, I would like to retrieve the properties of the target (get_target_property(my_compilation_flags TARGET COMPILE_FLAGS)), and then modify those and use it to set the properties of the target. Two questions for me remain: 1- How do I get *all* the compilation flags used for a target? get_target_property doesn't return flags is CXX_COMPILE_FLAGS nor those added by add_compile_options. 2- How do I *replace* compilation flags and don't *add* compilation flags? Both target_compile_options and set_target_properties seems to *add* flags and don't replace. Everything is tested under linux and cmake 3.13.3. Thanks for you help, any pointer to a ressource that might contain useful information for this problem would be really appreciated. Regards, -- Benjamin Orgogozo From daniel.wynne at mobotix.com Thu Apr 4 10:51:19 2019 From: daniel.wynne at mobotix.com (Daniel Wynne) Date: Thu, 4 Apr 2019 16:51:19 +0200 Subject: [CMake] Android Cross Compilation with Xamarin In-Reply-To: References: Message-ID: <3900b468-352c-fccc-c340-a26568d853c7@mobotix.com> Hi All! Wwe would like to set up a Android cross compilation project for Visual Studio using the Xamarin Framework. Could you please give us a few hints on what would be the best approach to achieve this? Another question is, why the NVidia Tegra Plugin is mandatory for Visual Studio and no self-provided NDK/Toolchain is supported when it comes to Visual Studio and Android development? Thank you very much! Kind Regards Daniel Wynne -- This e-mail was sent from a contact form on CMake (https://cmake.org) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Thu Apr 4 12:00:43 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 4 Apr 2019 18:00:43 +0200 Subject: [CMake] Remove compilation flags for a given target In-Reply-To: <20190404123111.GA11793@drus> References: <20190404123111.GA11793@drus> Message-ID: On Thu, 4 Apr 2019 at 14:47, Benjamin Orgogozo wrote: > > If I'm right (I'm far from being a cmake expert) there are two ways to > define "global" compilation flags: > 1- set the CXX_COMPILE_FLAGS variable; > 2- use add_compile_options($<$:-WMyFavouriteWarning). The list should rather be, in preference/priority order 1. https://cmake.org/cmake/help/latest/command/target_compile_options.html 2. add_compile_options And, if you really, really need 3. append to CMAKE_CXX_FLAGS > Since I don't want to *add* a compilation flags but remove one, I would > like to retrieve the properties of the target > (get_target_property(my_compilation_flags TARGET COMPILE_FLAGS)), and > then modify those and use it to set the properties of the target. > > Two questions for me remain: > 1- How do I get *all* the compilation flags used for a target? > get_target_property doesn't return flags is CXX_COMPILE_FLAGS nor those > added by add_compile_options. Are you certain you've got the variable name right? https://cmake.org/cmake/help/latest/search.html?q=CXX_COMPILE_FLAGS > 2- How do I *replace* compilation flags and don't *add* compilation > flags? Both target_compile_options and set_target_properties seems to > *add* flags and don't replace. See https://cmake.org/pipermail/cmake/2018-December/068716.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From francis.giraldeau at gmail.com Thu Apr 4 13:48:54 2019 From: francis.giraldeau at gmail.com (Francis Giraldeau) Date: Thu, 4 Apr 2019 13:48:54 -0400 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: Maybe the problem is related to Cotire? I see that it is used in mredis. I tried to reproduce the issue, and it behaves correctly. You might want to try to reproduce using the following minimal repo: https://gitlab.com/fgiraldeau/cotire-demo Francis Le jeu. 4 avr. 2019 ? 03:17, Stephan Menzel a ?crit : > > Hello Paul and Shoaib, > > I'm answering to the both of you. > > On Thu, Apr 4, 2019 at 7:13 AM Paul Smith wrote: >> >> Now although I don't understand the exact reasons behind that, over the years came to accept that depedencies between the lib and the resulting artifcats are not working. Like, when I change a source file to mylib, the lib will get rebuilt but the resulting test tool won't be relinked. >> >> >> This is definitely not true, as stated. I feel like I must be missing something about your stated environment because this is really basic, fundamental CMake behavior, which has always worked. > > > First of all, thanks for the information. I was not aware that this is supposed to work. As I said, I've been struggling with this issue for years now and I recall posting this to this list too but the only explanation I ever found was something along the lines of "dependencies would exist to objects inside the lib, not the lib as it is a static archive". But I'm pulling this out of my 'memory' now, nothing to rely on. All I remembered is that this is not supposed to work. But now you say the opposite, which gives me a little hope. > >> >> If in your environment you are not seeing executables rebuilt when libraries they depend on are updated, then there is something more complex about it than the straightforward case you provide above. > > > I have seen this in two major projects I have been working on in the last years. Both were Linux and Windows, MSVC 14 and 15 on Windows. And I do believe the issue is on Windows. I am not sure which CMake version I have seen this first on. Let's make it 3.10.x cause this was when I posted this to the list last time but by then I was already having the problem for a longer time. > > Today I am using CMake version 3.13.2 but I have been using many different versions up to this one. > > Both projects were large but not huge, having about 10 - 15 targets plus additional 50 unit tests plus another 5 test tools. Unfortunately I cannot publish the projects themselves but one that I currently see the issue with is mredis (https://github.com/MrMoose/mredis) which, among others, is pulled in as a submodule. C++ only, some protobuf code generation is involved but not in the targets that I'm talking about. > > Since the issue has been persisting for so long now, the projects and CMakeLists have substantially changed many times, so it's really hard to come up with something I would consider 'strange' or 'different' as a possible explanation. > > -- > > 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 benshadwick at gmail.com Thu Apr 4 18:07:08 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Thu, 4 Apr 2019 15:07:08 -0700 Subject: [CMake] Eclipse generator question In-Reply-To: <18958659.nXjFP0nX28@linux> References: <1907275.WsIYnJSqm2@linux> <18958659.nXjFP0nX28@linux> Message-ID: Ah, it seems my CMake is too old to produce compile_commands.json. Maybe this is part of why other IDEs are working better at home on Ubuntu MATE LTS. Unfortunately Red Hat ships CMake 2.8.12.2 even in recent RHEL releases, which is now approaching 5 years old (yikes!). Apparently they ship CMake 3.13.4 as a 'cmake3' package and I didn't catch it - will see if I can upgrade at least some of my machines. On Thu, Apr 4, 2019 at 2:07 PM Martin Weber wrote: > Am Mittwoch, 3. April 2019, 23:52:38 CEST schrieben Sie: > > On Wed, Apr 3, 2019 at 2:18 PM Martin Weber > > > > wrote: > > > Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick: > > > > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of > > > > > > tweaking > > > > > > Really? Just set _CMake Builder (portable)_ as the current builder and > > > build. > > > > It required a lot more tweaking than that for an out of source build, > > cmake4eclipse enforces out of source build by default, with the build > directory below project root. > > > including manually enabling the CMAKE includes and defines providers. > > cmake4eclipse is not a tool to configure your project. Aside from that, > the > CDT API does not allow to fully configure a project programatically. > > > > > > > of the Eclipse project after you create it, and I'm pretty sure it > > > > > > suffers > > > > > > > from the same problem of leaving you with an Eclipse project whose > > > > source > > > > tree reflects what is in the filesystem rather than what is defined > in > > > > > > the > > > > > > > CMake project. > > > > > > What does that mean: _an Eclipse project whose source tree reflects > what > > > is in > > > the filesystem rather than what is defined in the CMake project._ ?? > > > > This is exactly what I'm getting at: People have marinated so much in the > > way Eclipse works by default that what I'm saying sounds like a non > > sequitur. > > > > I'll try to explain: > > - I have a repository with a large source tree that contains hundreds of > > leaf directories. > > - Each leaf directory contains source that needs to be built into a > shared > > library or an executable binary. > > - The source tree contains a superset of the functionality that is needed > > by all configurations. > > - Any particular configuration of the CMake project will result in only a > > subset of the libraries and/or binaries being built. > > - The subset being built is defined via CMake option() commands that set > > (or don't) cache variables that control which subdirectories are added to > > the CMake project. > > > > What I want from Eclipse: > > - Only show in the project tree and Open Resource dialog the subset of > > source files that belong to the current configuration of the CMake > project, > > so that developers don't get confused about what is relevant or not to > the > > configuration of CMake they are working in. > > - Only index the subset of source files that belong to the current > > configuration of the CMake project, so that resources are not wasted > > indexing irrelevant sources, and so that developers are not flooded with > > irrelevant indexer errors. > > - Show header files that are assigned to a target, including custom > > header-only targets ("custom_target(... SOURCES)"), as is done by other > > IDEs. > > > > > If the IDE indexing all source files takes too long, I would say it is > a > > > problem with the IDE; but not a problem of cmake's IDE project > generator > > > (as > > > the topic states). > > > > Time is only one aspect (see above), although it's particularly bad with > > the out-of-box Eclipse project generated by CMake's default settings > > because it indexes every source file 3 times. > > Well, that's CDT. If you press 'Apply and Close' in the project property > dialog, if write the file 2 times to disk :-[ > > > > > > That's the only way to go in your case. How should the CDT4 project > > > generator > > > know about all your source files that do not take part in a build? > > > > The point I'm trying to make is that I *don't* want Eclipse to know about > > source files that are *not* being built, but it *does* know about them > > because all solutions (CMake generator, cmake4eclipse) just point Eclipse > > at the source tree *in the filesystem*, and not at the conceptual project > > tree defined via the CMakeLists.txt hierarchy. Remember that for me, the > > OK, I see your point. CDT indeed has no concept of 'conceptual project > tree' > as you name it. > But it has filters for files in the source tree! And these seem to operate > on > a per-configuration-base. > And cmake4eclipse already has a parser for the compile_commands.json file > produces by cmake. That file lists each file in the build. > > My idea to ease your problem is to have a menu action in the UI that > configures the source file filter of the project based on the files listed > in > the compile_commands.json file. > ... > > - Any particular configuration of the CMake project will result in only a > > subset of the libraries and/or binaries being built. > > - The subset being built is defined via CMake option() commands that set > > (or don't) cache variables that control which subdirectories are added to > > the CMake project. > > You would create a CDT project configuration for one of the particular > configuration of your CMake project and define the corresponding CMake > option() values on the cmake4eclipse Symbols tab, build the project to > create > the compile_commands.json file. Then run the menu action and let it adjust > the > source file filter. > Of course you would have to repeat the actions above for each of your > particular configurations. > > But my idea would only help iff > -) compile_commands.json file lists only the source files that take part > in > the build. > -) CDT's indexer indeed respects the filter for source files. > -) Concerning your point ' Show header files that are assigned to a > target, > including custom header-only targets', I'm not sure whether CDT supports > that. > Its 'Include Directories' folder view is unmaintained since years. > > A final warning: > My suggestion is based on cmake4eclipse (it is around since 2013), and > that is > based on the 'CDT Managed Build System'. > In 2018, the CDT project lead decided to deprecate 'Managed Build' and to > replace it with sth. called Core Build. AFAICT, Core Build requires You to > provide makefiles to build and is focused on GCC/emdedde controllers ATM. > CDT > Core Build claims to have additional cmake support but; (I'm biased:) WTF. > To summarize my warning: If your product lifecycle is at +5 years, lookout > for > a different IDE. Or split it into sub-projects with individual releases. > > Martin > > -- > Cd wrttn wtht vwls s mch trsr. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Cook at riotinto.com Thu Apr 4 23:25:48 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Fri, 5 Apr 2019 03:25:48 +0000 Subject: [CMake] Setting permissions with CPack/WiX installer Message-ID: Hi all, I would like to set the permissions on some files and directories in my WiX installer. It looks like the CPACK_WIX_ACL property should be suitable, but I can't get it to work. There are examples of its usage in this project: https://github.com/ngladitz/cmake-wix-testsuite/tree/master/properties Typically something like this: set_property(INSTALL empty_directory_with_property non_empty_directory_with_property PROPERTY CPACK_WIX_ACL "Everyone=GenericRead,GenericWrite,CreateFile" ) but this example doesn't work for me with cmake 3.14.0. None of the .wxs files that are produced contain the expected Permission property. After adding some debugging to cmake, I found that cmCPackWIXGenerator::AddDirectoryAndFileDefinitions calls GetInstalledFile, which always returns NULL. This prevents the ACL from being applied. As an alternative, I've tried to use CPACK_WIX_PATCH_FILE to specify the Permission property for the relevant fragments, but the patch does not get applied to the fragments where directories are created. In any case, I think CPACK_WIX_ACL would be preferable if I could get it to work. Can anyone provide a minimal working example that uses CPACK_WIX_ACL? Thanks Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Fri Apr 5 01:32:10 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Fri, 5 Apr 2019 06:32:10 +0100 Subject: [CMake] Fake dependencies of executables to static libs In-Reply-To: References: Message-ID: Hello Francis, On Thu, Apr 4, 2019 at 6:49 PM Francis Giraldeau < francis.giraldeau at gmail.com> wrote: > Maybe the problem is related to Cotire? I see that it is used in > mredis. I tried to reproduce the issue, and it behaves correctly. You > might want to try to reproduce using the following minimal repo: Alas, I can safely rule out cotire. I only included it a few months ago and the issue was already ages old by then. Also, it is optional and some use it, some don't. What comes to mind now as a possible explanation, as I just a minute ago noticed is what button to press. Perhaps it is a Visual Studio thing. When I, for example, work on the mredis lib I do that test driven using the various testing tools. Now in order to do this, I generally set the testing suite as "StartUp Project", as VC calls the currently active target. Then I press 'build target' (as opposed to 'build solution') or simply just "Debug", the green play button to run a test. When the source to the testing suite is changed, both operations cause build and link of the tool and then run it as they should. When I change a source in the lib they do not. However, when I press 'build solution', all dependent binaries do seem to be relinked. I just tested this. It's simply that I normally don't do this for low level testing builds because I don't need to build the whole solution just for one test. Interesting. I never noticed that. May this shed some light on the issue? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 5 05:27:52 2019 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 5 Apr 2019 11:27:52 +0200 Subject: [CMake] Setting permissions with CPack/WiX installer In-Reply-To: References: Message-ID: On Fri, Apr 5, 2019 at 5:25 AM Cook, Steven (G&I) wrote: > Hi all, > > > > I would like to set the permissions on some files and directories in my > WiX installer. It looks like the CPACK_WIX_ACL property should be suitable, > but I can?t get it to work. There are examples of its usage in this project: > > https://github.com/ngladitz/cmake-wix-testsuite/tree/master/properties > > > > Typically something like this: > > set_property(INSTALL > > empty_directory_with_property > > non_empty_directory_with_property > > PROPERTY CPACK_WIX_ACL ?Everyone=GenericRead,GenericWrite,CreateFile? > > ) > > > > but this example doesn?t work for me with cmake 3.14.0. None of the .wxs > files that are produced contain the expected Permission property. After > adding some debugging to cmake, I found that > cmCPackWIXGenerator::AddDirectoryAndFileDefinitions calls GetInstalledFile, > which always returns NULL. This prevents the ACL from being applied. > Been a while since I looked at this but it still seems to work for me in 3.14.0. Corresponding elements are generated in files.wxs: Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Fri Apr 5 13:57:39 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 05 Apr 2019 19:57:39 +0200 Subject: [CMake] Eclipse generator question In-Reply-To: References: <18958659.nXjFP0nX28@linux> Message-ID: <3503511.be7WHX5M6d@linux> Am Freitag, 5. April 2019, 00:07:08 CEST schrieb Benjamin Shadwick: > Ah, it seems my CMake is too old to produce compile_commands.json. Maybe > this is part of why other IDEs are working better at home on Ubuntu MATE > LTS. > > Unfortunately Red Hat ships CMake 2.8.12.2 even in recent RHEL releases, > which is now approaching 5 years old (yikes!). Apparently they ship CMake > 3.13.4 as a 'cmake3' package and I didn't catch it - will see if I can > upgrade at least some of my machines. They don't! Maybe you find a more recent RPM at https://build.opensuse.org/ and ask the package maintainer there to also build it for RHEL. I took the same approach on our company-internal OBS. -- Cd wrttn wtht vwls s mch trsr. From kyle.edwards at kitware.com Fri Apr 5 15:17:26 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 05 Apr 2019 15:17:26 -0400 Subject: [CMake] Ubuntu CMake Repository Now Available Message-ID: <1554491846.5439.45.camel@kitware.com> All, I am pleased to announce that Kitware is now offering an officially-supported set of Ubuntu packages for CMake. These CMake packages can be installed with apt-get, just like other Ubuntu packages. We currently support Ubuntu 16.04 and 18.04. The following packages are available: * cmake - Contains the CMake command line executable, CTest, and CPack. * cmake-curses-gui - Contains ccmake. * cmake-qt-gui - Contains cmake-gui. * cmake-doc - Contains the CMake documentation. To use these packages, follow the instructions at https://apt.kitware.com/ to add our APT repository to your Ubuntu installation, and then use apt-get install to install one or all of the above packages. We currently offer CMake 3.14.1, and will continue to update the repository as new CMake releases are issued. Kyle From dmitigr at gmail.com Fri Apr 5 15:53:41 2019 From: dmitigr at gmail.com (Dmitry Igrishin) Date: Fri, 5 Apr 2019 22:53:41 +0300 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: <1554491846.5439.45.camel@kitware.com> References: <1554491846.5439.45.camel@kitware.com> Message-ID: Thats great! Thank you! ??, 5 ???. 2019 ?. ? 22:17, Kyle Edwards via CMake : > > All, > > I am pleased to announce that Kitware is now offering an > officially-supported set of Ubuntu packages for CMake. These CMake > packages can be installed with apt-get, just like other Ubuntu > packages. We currently support Ubuntu 16.04 and 18.04. > > The following packages are available: > > * cmake - Contains the CMake command line executable, CTest, and CPack. > * cmake-curses-gui - Contains ccmake. > * cmake-qt-gui - Contains cmake-gui. > * cmake-doc - Contains the CMake documentation. > > To use these packages, follow the instructions at > > https://apt.kitware.com/ > > to add our APT repository to your Ubuntu installation, and then use > apt-get install to install one or all of the above packages. > > We currently offer CMake 3.14.1, and will continue to update the > repository as new CMake releases are issued. > > Kyle > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From sergey.nikulov at gmail.com Fri Apr 5 16:15:37 2019 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Fri, 5 Apr 2019 23:15:37 +0300 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: <1554491846.5439.45.camel@kitware.com> References: <1554491846.5439.45.camel@kitware.com> Message-ID: It would be great to see officialy supported rpm repository for CentOS/Fedora as well! Thank you in advance. ??, 5 ???. 2019 ?., 22:17 Kyle Edwards via CMake : > All, > > I am pleased to announce that Kitware is now offering an > officially-supported set of Ubuntu packages for CMake. These CMake > packages can be installed with apt-get, just like other Ubuntu > packages. We currently support Ubuntu 16.04 and 18.04. > > The following packages are available: > > * cmake - Contains the CMake command line executable, CTest, and CPack. > * cmake-curses-gui - Contains ccmake. > * cmake-qt-gui - Contains cmake-gui. > * cmake-doc - Contains the CMake documentation. > > To use these packages, follow the instructions at > > https://apt.kitware.com/ > > to add our APT repository to your Ubuntu installation, and then use > apt-get install to install one or all of the above packages. > > We currently offer CMake 3.14.1, and will continue to update the > repository as new CMake releases are issued. > > Kyle > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Fri Apr 5 22:56:25 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Fri, 5 Apr 2019 19:56:25 -0700 Subject: [CMake] Remove compilation flags for a given target In-Reply-To: <20190404123111.GA11793@drus> References: <20190404123111.GA11793@drus> Message-ID: > > > in our code base we would like to add a warning compilation flags. > Nevertheless, this flag prevents us from compiling a few targets so we > would like to remove this flag for the given targets. > > Since I don't want to *add* a compilation flags but remove one, I would > like to retrieve the properties of the target > (get_target_property(my_compilation_flags TARGET COMPILE_FLAGS)), and > then modify those and use it to set the properties of the target. > Instead of removing, have you tried appending the -Wno-fubar flag that turns back off these specific warnings for these specific files? With gcc for instance: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html "Each of these specific warning options also has a negative form beginning ?-Wno-? to turn off warnings; for example, -Wno-implicit. [...] For options of the same specificity, the last one takes effect" -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Fri Apr 5 23:00:10 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Fri, 5 Apr 2019 20:00:10 -0700 Subject: [CMake] Better way than: SET(CMAKE_C_ARCHIVE_CREATE " my_flags ... ? In-Reply-To: References: Message-ID: Additional issue with this CMAKE_C_ARCHIVE_CREATE hack: it's ignored and reverts back to the default in link.txt when building a "pure assembly" library without any .c file. Adding an empty.c file works around the problem. Is this expected? Reproduced with CMake 3.13 and 3.14.0. Le lun. 25 f?vr. 2019 ? 11:41, Marc Herbert a ?crit : > Hi, > > 1. I found the hack below in the list's archive. However it seems... > hackish. Among others it can't _append_ a flag, it can only replace all > flags. Any newer and better way to append some extra flags? > > 2. Bonus question: how would you query "ar" and append some extra flags > *only* when ar/ranlib are new enough to support them? > > Thanks in advance, > > Marc > > SET(CMAKE_C_ARCHIVE_CREATE " -qcD > ") > SET(CMAKE_C_ARCHIVE_FINISH " -D ") > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo.bramini at gmail.com Sat Apr 6 05:24:57 2019 From: carlo.bramini at gmail.com (Carlo B.) Date: Sat, 6 Apr 2019 11:24:57 +0200 Subject: [CMake] Building stuff with CMake and DJGPP. Message-ID: Hello, I would like to use DJGPP for compiling a library or an application with CMAKE build system. Unfortunately, it is not clear to me how to do so... I have written a toolchain file and I set CMAKE_SYSTEM_NAME to Generic and basically it works, but obviously CMakeLists.txt is not able to distibuish and so it cannot add some files/libraries required by this platform. Have you some suggestions for doing this? Sincerely. From cary at txcorp.com Sat Apr 6 12:23:48 2019 From: cary at txcorp.com (JR Cary) Date: Sat, 6 Apr 2019 10:23:48 -0600 Subject: [CMake] enable_language(CUDA) and long command lines on windows Message-ID: <4f56ef9b-6c4e-d0b7-58a1-592c409ef0a8@txcorp.com> Porting our cmake build system to use enable_language(CUDA). This is a complex computational application that make use of many libraries.? Upon doing this, add_executable ended up generating a link line of 9455 chars, causing Windows cmd to fail to execute it.? In addition, the final link used nvcc instead of cl, as used to be the case, even though the one and only source file is a cxx file. Had a similar problem in creating shared libraries. So my questions are: 1. How can I force the use of link.exe instead of nvcc.exe with enable_language(CUDA)? 2. If that does not solve the problem of long link lines, how can I solve that with an external file specifying the link, as is done without enable_language(CUDA)? Thanks....John Cary PS: In case anyone finds this of use... a) I had to remove cudart_static from CMAKE_CUDA_IMPLICIT_LINK_LIBRARIES to get my windows shared libs to build, as they were linking to plain old cudart. b) To get reconfiguring to work, I had put ??? set(CMAKE_CUDA_COMPILER_ID_RUN FALSE) # Workaround before include(${CMAKE_ROOT}/Modules/CMakeDetermineCUDACompiler.cmake) to get auto-reconfiguring to work. From d3ck0r at gmail.com Sun Apr 7 06:32:33 2019 From: d3ck0r at gmail.com (J Decker) Date: Sun, 7 Apr 2019 03:32:33 -0700 Subject: [CMake] 3.14.1 Issue with external project? Message-ID: Under linux, I recently updated everything, and now have cmake 3.14.1. It's failing to build a project which has external projects with external projects itself... I'm not sure what a simple case is that fails. The previous version that worked was 3.13.4 (3.12.4 also) On Windows I was using cmake version 3.10.0-rc3 without issue, I grabbed the latest 3.14.1 zip and swapped to that, and it's having similar issues. Linux defaulted initially to ninja; but I overrode that and used 'Unix Makefiles' as a generator and the same issue happened. The project has an external project from a git repository, which it downloads, updates, configures, and builds; that project also has external projects (ppc is one of them) Well here; this log isn't huge. -- Configuring done -- Generating done -- Build files have been written to: /home/d3x0r/work/javascript/sack-gui/build/sack-src/src/sack-build [3/5] Performing build step for 'sack' [1/3] Performing build step for 'ppc_portable' ninja: no work to do. [2/3] Performing install step for 'ppc_portable' [0/1] Install the project... -- Install configuration: "Debug" -- Up-to-date: /home/d3x0r/work/javascript/sack-gui/build/sack-Debug/bin/ppc [3/3] Completed 'ppc_portable' [4/5] Performing install step for 'sack' [1/4] Performing build step for 'ppc_portable' ninja: no work to do. [2/4] Performing install step for 'ppc_portable' [0/1] Install the project... -- Install configuration: "Debug" -- Up-to-date: /home/d3x0r/work/javascript/sack-gui/build/sack-Debug/bin/ppc [3/4] Completed 'ppc_portable' [3/4] Install the project... -- Install configuration: "Debug" [5/5] Completed 'sack' ----------- And then it ends, and doesn't build either the second external project, or the main project itself which depends on the external project ------------- Windows is somehow getting up to installing sack, ppc like above, but then fails with 'project file does not exist' and yet a directory of that name shows it does exist..... Performing install step for 'sack' Microsoft (R) Build Engine version 14.0.25420.1 Copyright (C) Microsoft Corporation. All rights reserved. MSBUILD : error MSB1009: Project file does not exist. [M:\javascript\sack-gui\build\sack.vcxproj] Switch: install ERR! OMG Process terminated: 1 M:\javascript\sack-gui>dir M:\javascript\sack-gui\build\sack.vcxproj Volume in drive M is Work3 Volume Serial Number is 5EC6-2ABD Directory of M:\javascript\sack-gui\build ---------------- This branch of this repository https://github.com/d3x0r/sack.vfs/tree/sack-gui mkdir build cd build cmake -DMAKE_GUI=1 -DCMAKE_BUILD_TYPE=Debug .. cmake --build . and it ends with building sack and nothing else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sun Apr 7 06:50:20 2019 From: d3ck0r at gmail.com (J Decker) Date: Sun, 7 Apr 2019 03:50:20 -0700 Subject: [CMake] 3.14.1 Issue with external project? In-Reply-To: References: Message-ID: > > Sorry it's probably a user error. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Cook at riotinto.com Sun Apr 7 20:07:38 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Mon, 8 Apr 2019 00:07:38 +0000 Subject: [CMake] Setting permissions with CPack/WiX installer In-Reply-To: References: Message-ID: Hi Nils, > Been a while since I looked at this but it still seems to work for me in 3.14.0. > Corresponding elements are generated in files.wxs: Can you please tell me the commands you used to run cpack? I did the following, which didn?t give the Permission elements. cd cmake-wix-testsuite-master\properties cmake -DCPACK_GENERATOR=WIX . cpack -DCPACK_GENERATOR=WIX . Full output is below. Thanks, Steve Steven.Cook at AUPERWL01583 C:\dev\GI > cd cmake-wix-testsuite-master\properties Steven.Cook at AUPERWL01583 C:\dev\GI\cmake-wix-testsuite-master\properties > cmake -DCPACK_GENERATOR=WIX . -- Building for: Visual Studio 15 2017 -- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.15063. -- The C compiler identification is MSVC 19.16.27030.1 -- The CXX compiler identification is MSVC 19.16.27030.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.14) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done -- Generating done -- Build files have been written to: C:/dev/GI/cmake-wix-testsuite-master/properties Steven.Cook at AUPERWL01583 C:\dev\GI\cmake-wix-testsuite-master\properties > cpack -DCPACK_GENERATOR=WIX . CPack: Create package using WIX CPack: Install projects CPack: - Install project: Project CPack: Create package CPack Warning: CPACK_WIX_UPGRADE_GUID implicitly set to 26D57C14-30E5-4837-95E3-5C5E9317CE0F . Please refer to the documentation on how and why you might want to set this explicitly. CPack: - package: C:/dev/GI/cmake-wix-testsuite-master/properties/Project-0.1.1-win32.msi generated. files.wxs contains the following, but no Permission elements: > cmake --version cmake version 3.14.0 CMake suite maintained and supported by Kitware (kitware.com/cmake). > candle --version Windows Installer XML Toolset Compiler version 3.11.1.2318 Copyright (c) .NET Foundation and contributors. All rights reserved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 8 04:48:25 2019 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 8 Apr 2019 10:48:25 +0200 Subject: [CMake] Setting permissions with CPack/WiX installer In-Reply-To: References: Message-ID: On Mon, Apr 8, 2019 at 2:07 AM Cook, Steven (G&I) wrote: > Hi Nils, > > > > > Been a while since I looked at this but it still seems to work for me > in 3.14.0. > > > Corresponding elements are generated in files.wxs: > > > > Can you please tell me the commands you used to run cpack? I did the > following, which didn?t give the Permission elements. > Remove this line https://github.com/ngladitz/cmake-wix-testsuite/blob/master/CMakeLists.txt#L15 (I think it is superfluous/wrong and errors out when using newer cmake versions). >From a command line environment where your compiler is properly set up and ninja is in PATH configure the root of the project with the Ninja generator (currently hardcoded in the tests); use an out of source build directory and set the REFERENCE_CMAKE_BIN_DIR cache variable to the bin-Directory of the CMake installation you want to test. Run e.g. "ctest -R properties" from the build directory. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From cary at txcorp.com Mon Apr 8 10:51:29 2019 From: cary at txcorp.com (JR Cary) Date: Mon, 8 Apr 2019 08:51:29 -0600 Subject: [CMake] enable_language(CUDA) and long command lines on windows Message-ID: <6f33f734-46ca-6c4f-12ef-c70922c1584b@txcorp.com> Regarding the previous email, below.... The method of library construction is to first create an object library with add_library(${libname}obj OBJECT ${${LIBNAME}_SOURCES} ${${LIBNAME}_CUDASRCS}) then to create the actual library with add_library(${libname} $) and I have tried setting: set_target_properties(${libname} PROPERTIES LINKER_LANGUAGE CXX) Thx....John Cary > Porting our cmake build system to use enable_language(CUDA). > This is a complex computational application that make use of > many libraries.? Upon doing this, add_executable ended up > generating a link line of 9455 chars, causing Windows cmd to > fail to execute it.? In addition, the final link used nvcc > instead of cl, as used to be the case, even though the one > and only source file is a cxx file. > > Had a similar problem in creating shared libraries. > > So my questions are: > > 1. How can I force the use of link.exe instead of nvcc.exe > with enable_language(CUDA)? > > 2. If that does not solve the problem of long link lines, > how can I solve that with an external file specifying the > link, as is done without enable_language(CUDA)? From dustyn at blasig.us Mon Apr 8 16:57:23 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Mon, 8 Apr 2019 15:57:23 -0500 Subject: [CMake] Object library build fails due to missing include folder from linked interface library Message-ID: Hi All, I have a component similar to this setup ... project(foo LANGUAGES CXX CUDA) add_library(foo INTERFACE) target_include_directories(foo INTERFACE ) add_library(bar OBJECT bar.cu) target_link_libraries(bar PUBLIC foo) When building *bar*, there is no "-I " in the command line fed to nvcc and the needed headers are therefore not available. I only see this issue with object libraries. I've tried using PRIVATE and INTERFACE instead of PUBLIC when defining the link library specification for *bar *with no luck. I'm trying to figure out if this is supposed to work, or a known limitation. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Cook at riotinto.com Tue Apr 9 02:09:12 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Tue, 9 Apr 2019 06:09:12 +0000 Subject: [CMake] Setting permissions with CPack/WiX installer In-Reply-To: References: Message-ID: Hi Nils, > From a command line environment where your compiler is properly set up and > ninja is in PATH configure the root of the project with the Ninja generator > (currently hardcoded in the tests); use an out of source build directory and > set the REFERENCE_CMAKE_BIN_DIR cache variable to the bin-Directory of the > CMake installation you want to test. > Run e.g. "ctest -R properties" from the build directory. Thanks, that helped but I am now stuck on a different error where it can't find the rc command. I have modified PATH to include the rc directory (C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64) but it still can't find it. RC Pass 1: command "rc /foCMakeFiles\cmTC_0bc1e.dir/manifest.res CMakeFiles\cmTC_0bc1e.dir/manifest.rc" failed (exit code 0) with the following output: The system cannot find the file specified I have made a very simple example that generates a WIX installer for a single file but fails to set the permissions on the file. Do you have any suggestions of why this isn't working? cmake_minimum_required(VERSION 2.8.12) install( FILES test.txt DESTINATION ./ ) set_property(INSTALL test.txt PROPERTY CPACK_WIX_ACL "Everyone=GenericRead,GenericWrite" ) set( CPACK_GENERATOR WIX ) include(CPack) Thanks Steve From borgogozo at antidot.net Tue Apr 9 02:44:02 2019 From: borgogozo at antidot.net (Benjamin Orgogozo) Date: Tue, 9 Apr 2019 08:44:02 +0200 Subject: [CMake] Remove compilation flags for a given target In-Reply-To: References: <20190404123111.GA11793@drus> Message-ID: <20190409064402.GA4079@drus> On Thu, Apr 04, 2019 at 06:00:43PM +0200, Mateusz Loskot wrote: > The list should rather be, in preference/priority order > > 1. https://cmake.org/cmake/help/latest/command/target_compile_options.html > 2. add_compile_options Yes, it's what I understood from documentation. > Are you certain you've got the variable name right? > https://cmake.org/cmake/help/latest/search.html?q=CXX_COMPILE_FLAGS Yes yes, I triple checked it. But I would have preferred to have made an error here. :) > See https://cmake.org/pipermail/cmake/2018-December/068716.html Thanks for the link and your time. -- Benjamin Orgogozo From borgogozo at antidot.net Tue Apr 9 02:47:30 2019 From: borgogozo at antidot.net (Benjamin Orgogozo) Date: Tue, 9 Apr 2019 08:47:30 +0200 Subject: [CMake] Remove compilation flags for a given target In-Reply-To: References: <20190404123111.GA11793@drus> Message-ID: <20190409064730.GB4079@drus> On Fri, Apr 05, 2019 at 07:56:25PM -0700, Marc Herbert wrote: > Instead of removing, have you tried appending the -Wno-fubar flag that > turns back off these > specific warnings for these specific files? Ah, yes, it will actually work... Not the answer that I was expecting but clearly a solution for this particular problem. I find it strange that there is no way to remove properties from a target but it seems that it is really not possible... Thanks for you help! -- Benjamin Orgogozo From embedded.team103 at gmail.com Tue Apr 9 08:30:49 2019 From: embedded.team103 at gmail.com (Israel Israeli) Date: Tue, 9 Apr 2019 15:30:49 +0300 Subject: [CMake] Configuration time "custom command" Message-ID: Hello, We are using a large project that comes with it's own build and configuration system. We have multiple issues with this external build system and we want to move the building of this project to cmake (as well as our code that depends on it). All the problems are related to the `build` step and we want to replace it with a simple `add_library` with all sources. The problem starts due to the fact that the project's configuration process is complicated and ever-changing, and we do not want to maintain a copy of it inside cmake. Instead, we want to call `execute_process` to get cmake variables needed from the external configuration system and have a simple cmake build steps on top of it. The thing is we want proper detection of when to rerun the configure step and we want something similar to `add-custom_target`'s DEPENDS variable, only at configure time. Is this possible by any means? I know of `CMAKE_CONFIGURE_DEPENDS`, but the fact that it is global is problematic and here's why: There are multiple cmake variables that come from this configuration system - from the language standard version to the list of target sources. Change in what creates one of them should NOT trigger the configuration system for another variable as this could cause a full rebuild of the project which is undesirable due to long compilation times. Basically, what I'm asking is* - Is there a way to describe "custom commands", with proper dependency management that run at configure time?* Example (pseudo cmake): add_custom_configure_command(GetLinkerScript COMMAND some_external_program1.exe OUTPUT_VARIABLE LINKER_SCRIPT DEPENDS version_file.json) add_custom_configure_command(GetSourcesList COMMAND some_external_program2.exe OUTPUT_VARIABLE SOURCES DEPENDS config_file.json) add_library(MyLib) target_sources(MyLib PUBLIC ${SOURCES}) #Add custom target for the linker script that if it changes the lib needs to be re-linked add_custom_target(LinkerScript ...) Is there a way to achieve this behavior (namely if I change the linker script, then generating the list of sources won't happen - and not a rebuild)? Note this is just an example, in reality I have 10 different cmake variables with different purposes that are outputted from the external configuration system - but the dependencies are quite clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From embedded.team103 at gmail.com Tue Apr 9 10:03:39 2019 From: embedded.team103 at gmail.com (Israel Israeli) Date: Tue, 9 Apr 2019 17:03:39 +0300 Subject: [CMake] Working around target needing many include directories Message-ID: We are using a library that adds all of it's subdirectories to the include search path (hundreds of directories and thousands of files). This is done because they change their folder structure constantly (but we don't care as we are upgrading every once in a while and can adjust). We don't want this for our usage as the file names are very generic and can cause name clashes (`Queue.h` for example) with other third party libs. We want to rewrite their build system (which is not cmake originally, but that is a different story) so that this addition of include directories is private. Namely simple write: target_include_directories(Lib PRIVATE ${LIB_SUBDIRECTORIES}) Here is the problem and question: When building the lib like this, everything works great, but when our project that depends on the library is built, there are preprocessor errors - we include files from the library which in turn include other lib files with non relative includes - and in our target build step the compiler does not have the include directories needed to resolve the non relative include. Example: Lib dirA file_a.h dirB file_b.h //file_a.h #include "file_b.h" //main.cpp #include "Lib\dirA\file_a.h" App main.cpp //CMake builds `Lib` okay. //CMake fails to build `App` due to non-relative include in `file_a.h` Is there a way to have it both ways? Build the library with all include paths, and in target depending on it - not add all of them? Can precompiled headers do this? Is there a pure cmake solution? -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Tue Apr 9 11:43:48 2019 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 9 Apr 2019 17:43:48 +0200 Subject: [CMake] Remove compilation flags for a given target In-Reply-To: <20190409064730.GB4079@drus> References: <20190404123111.GA11793@drus> <20190409064730.GB4079@drus> Message-ID: I believe that your targets should be using something like: target_compile_options(yourlib PRIVATE -Wwhatever) They will be built with said warnings, but it won't be propagated to consumers of the library. So you shouldn't have to remove anything. On Tue, Apr 9, 2019 at 8:47 AM Benjamin Orgogozo wrote: > On Fri, Apr 05, 2019 at 07:56:25PM -0700, Marc Herbert wrote: > > Instead of removing, have you tried appending the -Wno-fubar flag that > > turns back off these > > specific warnings for these specific files? > > Ah, yes, it will actually work... Not the answer that I was expecting > but clearly a solution for this particular problem. > I find it strange that there is no way to remove properties from a > target but it seems that it is really not possible... > > Thanks for you help! > > -- > Benjamin Orgogozo > -- > > 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 hahnse at ornl.gov Tue Apr 9 15:24:52 2019 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Tue, 9 Apr 2019 19:24:52 +0000 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: <1554491846.5439.45.camel@kitware.com> References: <1554491846.5439.45.camel@kitware.com> Message-ID: <7854EB76-2679-4DE5-AC1A-6203B4069034@ornl.gov> Would you consider updating the Ubuntu 18.04 package to depend on libcurl4? Unfortunately libcurl3 conflicts with libcurl4, and I need to keep the later installed for packages that depend on it. The Ubuntu-provided CMake package appears to be built against libcurl4. Steven ?On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" wrote: All, I am pleased to announce that Kitware is now offering an officially-supported set of Ubuntu packages for CMake. These CMake packages can be installed with apt-get, just like other Ubuntu packages. We currently support Ubuntu 16.04 and 18.04. The following packages are available: * cmake - Contains the CMake command line executable, CTest, and CPack. * cmake-curses-gui - Contains ccmake. * cmake-qt-gui - Contains cmake-gui. * cmake-doc - Contains the CMake documentation. To use these packages, follow the instructions at https://apt.kitware.com/ to add our APT repository to your Ubuntu installation, and then use apt-get install to install one or all of the above packages. We currently offer CMake 3.14.1, and will continue to update the repository as new CMake releases are issued. Kyle -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From ggarra13 at gmail.com Tue Apr 9 15:51:52 2019 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 9 Apr 2019 16:51:52 -0300 Subject: [CMake] RC compilation failing Message-ID: <6bcb05a3-4439-63e4-d557-0320455f317e@gmail.com> I had a resource.rc file and a resource.h file with just an ICON to provide the icon to my application.? However, since a week or so ago, RC refuses to compile it, giving the not very helpful message: Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336 Copyright (C) Microsoft Corporation.? All rights reserved. RC : fatal error RW1023: I/O error seeking in file According to the MSDEV pages that means I don't have disk space, but that's not true.? I checked permissions too and that seemed okay too. -- Gonzalo Garramu?o From benshadwick at gmail.com Tue Apr 9 16:38:45 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Tue, 9 Apr 2019 13:38:45 -0700 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: <7854EB76-2679-4DE5-AC1A-6203B4069034@ornl.gov> References: <1554491846.5439.45.camel@kitware.com> <7854EB76-2679-4DE5-AC1A-6203B4069034@ornl.gov> Message-ID: I believe it's possible to specify an "or" rule so that it would work with either package. It should probably require the one it's built against though, or at least prefer it if it works with both. On Tue, Apr 9, 2019 at 12:32 PM Hahn, Steven E. via CMake wrote: > Would you consider updating the Ubuntu 18.04 package to depend on libcurl4? > > Unfortunately libcurl3 conflicts with libcurl4, and I need to keep the > later installed for packages that depend on it. The Ubuntu-provided CMake > package appears to be built against libcurl4. > > Steven > > ?On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" < > cmake-bounces at cmake.org on behalf of cmake at cmake.org> wrote: > > All, > > I am pleased to announce that Kitware is now offering an > officially-supported set of Ubuntu packages for CMake. These CMake > packages can be installed with apt-get, just like other Ubuntu > packages. We currently support Ubuntu 16.04 and 18.04. > > The following packages are available: > > * cmake - Contains the CMake command line executable, CTest, and CPack. > * cmake-curses-gui - Contains ccmake. > * cmake-qt-gui - Contains cmake-gui. > * cmake-doc - Contains the CMake documentation. > > To use these packages, follow the instructions at > > https://apt.kitware.com/ > > to add our APT repository to your Ubuntu installation, and then use > apt-get install to install one or all of the above packages. > > We currently offer CMake 3.14.1, and will continue to update the > repository as new CMake releases are issued. > > Kyle > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Apr 9 18:03:37 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 09 Apr 2019 18:03:37 -0400 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: References: <1554491846.5439.45.camel@kitware.com> <7854EB76-2679-4DE5-AC1A-6203B4069034@ornl.gov> Message-ID: <1554847417.2883.22.camel@kitware.com> Rebuilt for 18.04 and verified to depend on libcurl4. The new package version is "3.14.1-0kitware1ubuntu18.04.1". Kyle On Tue, 2019-04-09 at 13:38 -0700, Benjamin Shadwick wrote: > I believe it's possible to specify an "or" rule so that it would work > with either package. It should probably require the one it's built > against though, or at least prefer it if it works with both. > > On Tue, Apr 9, 2019 at 12:32 PM Hahn, Steven E. via CMake > e.org> wrote: > > Would you consider updating the Ubuntu 18.04 package to depend on > > libcurl4? > > > > Unfortunately libcurl3 conflicts with libcurl4, and I need to keep > > the later installed for packages that depend on it. The Ubuntu- > > provided CMake package appears to be built against libcurl4. > > > > Steven > > > > ?On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" > > make-bounces at cmake.org on behalf of cmake at cmake.org> wrote: > > > > ? ? All, > > > > ? ? I am pleased to announce that Kitware is now offering an > > ? ? officially-supported set of Ubuntu packages for CMake. These > > CMake > > ? ? packages can be installed with apt-get, just like other Ubuntu > > ? ? packages. We currently support Ubuntu 16.04 and 18.04. > > > > ? ? The following packages are available: > > > > ? ? * cmake - Contains the CMake command line executable, CTest, > > and CPack. > > ? ? * cmake-curses-gui - Contains ccmake. > > ? ? * cmake-qt-gui - Contains cmake-gui. > > ? ? * cmake-doc - Contains the CMake documentation. > > > > ? ? To use these packages, follow the instructions at > > > > ? ? https://apt.kitware.com/ > > > > ? ? to add our APT repository to your Ubuntu installation, and then > > use > > ? ? apt-get install to install one or all of the above packages. > > > > ? ? We currently offer CMake 3.14.1, and will continue to update > > the > > ? ? repository as new CMake releases are issued. > > > > ? ? Kyle > > ? ? --? > > > > ? ? Powered by www.kitware.com > > > > ? ? Please keep messages on-topic and check the CMake FAQ at: http: > > //www.cmake.org/Wiki/CMake_FAQ > > > > ? ? Kitware offers various services to support the CMake community. > > For more information on each offering, please visit: > > > > ? ? CMake Support: http://cmake.org/cmake/help/support.html > > ? ? CMake Consulting: http://cmake.org/cmake/help/consulting.html > > ? ? CMake Training Courses: http://cmake.org/cmake/help/training.ht > > ml > > > > ? ? 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://ww > > w.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 zlynx at acm.org Tue Apr 9 19:30:39 2019 From: zlynx at acm.org (Zan Lynx) Date: Tue, 09 Apr 2019 17:30:39 -0600 Subject: [CMake] RC compilation failing In-Reply-To: <6bcb05a3-4439-63e4-d557-0320455f317e@gmail.com> References: <6bcb05a3-4439-63e4-d557-0320455f317e@gmail.com> Message-ID: <24C29642-19D9-4261-96FA-C06F64BC935B@acm.org> On April 9, 2019 1:51:52 PM MDT, "Gonzalo Garramu?o" wrote: >I had a resource.rc file and a resource.h file with just an ICON to >provide the icon to my application.? However, since a week or so ago, >RC >refuses to compile it, giving the not very helpful message: > >Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336 >Copyright (C) Microsoft Corporation.? All rights reserved. > >RC : fatal error RW1023: I/O error seeking in file > >According to the MSDEV pages that means I don't have disk space, but >that's not true.? I checked permissions too and that seemed okay too. I'm just a user of CMake. That doesn't sound like anything to do with CMake to me. I would try creating a fresh empty RC file and make sure that works. Then add the icon back. It's possible your source code control screwed up the newlines and "fixed" your icon if it thought it was a text file. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil From Steven.Cook at riotinto.com Tue Apr 9 21:49:55 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Wed, 10 Apr 2019 01:49:55 +0000 Subject: [CMake] Setting permissions with CPack/WiX installer In-Reply-To: References: Message-ID: > I have made a very simple example that generates a WIX installer for a > single file but fails to set the permissions on the file. Do you have any > suggestions of why this isn't working? Problem solved - when cpack is run with no parameters, the permissions tags are not generated, but when run with a -C parameter (eg cpack -C Debug) the permissions are generated as expected. I don't know why this would be the case, but I'm happy to have found the solution. Thanks, Steve From mario at emmenlauer.de Wed Apr 10 08:48:18 2019 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Wed, 10 Apr 2019 14:48:18 +0200 Subject: [CMake] AUTOMOC does not process headers in subdirectory of include/ Message-ID: <31aab211-889a-b536-fffa-77c1f2ebc336@emmenlauer.de> Dear all, we have a problem that Qt moc is only called for headers in the include directory of the project, not for subdirectories. Attached is a minimal example. cmake should call moc to generate the moc- sources in MyQtWidgets_autogen/include/bda/ folder. However the sources are not generated. When I move the header out of the subdirectory (from include/bda/CollapsibleDockWidget.hh to include/CollapsibleDockWidget.hh) and fix the include path in the source files, then moc works correctly. I think this is wrong, but I could not find explicit documentation about how the headers and sources are set for moc (see [1]). Does cmake not respect the headers listed with add_library()? Or is there something else I'm doing wrong? All the best, Mario Emmenlauer [1] https://cmake.org/cmake/help/latest/prop_tgt/AUTOMOC.html -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: MyQtWidgets.tar.gz Type: application/gzip Size: 1911 bytes Desc: not available URL: From sancelot at numalliance.com Wed Apr 10 11:26:10 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Wed, 10 Apr 2019 17:26:10 +0200 Subject: [CMake] linking FetchContent library Message-ID: <87f30061-54c4-9479-a749-5c016506617a@numalliance.com> Hi, are there any specific Cmake configurations to setup in projects when using fetchcontent. I am able to fetch and build a library but not able to link and include files of this library in another projects. include(FetchContent) FetchContent_Declare( ? jconcpp ? GIT_REPOSITORY https://github.com/joncol/jcon-cpp.git ) FetchContent_Populate(jconcpp) add_subdirectory(${jconcpp_SOURCE_DIR} ${jconcpp_BINARY_DIR}) Regards, S.Ancelot -------------- next part -------------- An HTML attachment was scrubbed... URL: From hahnse at ornl.gov Wed Apr 10 13:37:48 2019 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Wed, 10 Apr 2019 17:37:48 +0000 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: <1554847417.2883.22.camel@kitware.com> References: <1554491846.5439.45.camel@kitware.com> <7854EB76-2679-4DE5-AC1A-6203B4069034@ornl.gov> <1554847417.2883.22.camel@kitware.com> Message-ID: Thank you! I successfully installed your CMake 3.14.1 package this morning. Steven From: CMake on behalf of Kyle Edwards via CMake Reply-To: Kyle Edwards Date: Tuesday, April 9, 2019 at 6:04 PM To: Benjamin Shadwick , cmake Subject: Re: [CMake] Ubuntu CMake Repository Now Available Rebuilt for 18.04 and verified to depend on libcurl4. The new package version is "3.14.1-0kitware1ubuntu18.04.1". Kyle On Tue, 2019-04-09 at 13:38 -0700, Benjamin Shadwick wrote: I believe it's possible to specify an "or" rule so that it would work with either package. It should probably require the one it's built against though, or at least prefer it if it works with both. On Tue, Apr 9, 2019 at 12:32 PM Hahn, Steven E. via CMake > wrote: Would you consider updating the Ubuntu 18.04 package to depend on libcurl4? Unfortunately libcurl3 conflicts with libcurl4, and I need to keep the later installed for packages that depend on it. The Ubuntu-provided CMake package appears to be built against libcurl4. Steven On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" on behalf of cmake at cmake.org> wrote: All, I am pleased to announce that Kitware is now offering an officially-supported set of Ubuntu packages for CMake. These CMake packages can be installed with apt-get, just like other Ubuntu packages. We currently support Ubuntu 16.04 and 18.04. The following packages are available: * cmake - Contains the CMake command line executable, CTest, and CPack. * cmake-curses-gui - Contains ccmake. * cmake-qt-gui - Contains cmake-gui. * cmake-doc - Contains the CMake documentation. To use these packages, follow the instructions at https://apt.kitware.com/ to add our APT repository to your Ubuntu installation, and then use apt-get install to install one or all of the above packages. We currently offer CMake 3.14.1, and will continue to update the repository as new CMake releases are issued. Kyle -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Apr 10 17:03:04 2019 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 11 Apr 2019 07:03:04 +1000 Subject: [CMake] linking FetchContent library In-Reply-To: <87f30061-54c4-9479-a749-5c016506617a@numalliance.com> References: <87f30061-54c4-9479-a749-5c016506617a@numalliance.com> Message-ID: On Thu, Apr 11, 2019 at 1:35 AM St?phane Ancelot wrote: > Hi, > > are there any specific Cmake configurations to setup in projects when > using fetchcontent. > > I am able to fetch and build a library but not able to link and include > files of this library in another projects. > > include(FetchContent) > > FetchContent_Declare( > jconcpp > GIT_REPOSITORY https://github.com/joncol/jcon-cpp.git > ) > > FetchContent_Populate(jconcpp) > add_subdirectory(${jconcpp_SOURCE_DIR} ${jconcpp_BINARY_DIR}) > Can you provide a complete minimal example which shows the problem? The snippet above should bring jsoncpp into your main build, but without seeing how you are trying to link to it's targets, it is hard to tell what the problem could be. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjwrona1992 at gmail.com Wed Apr 10 17:08:31 2019 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Wed, 10 Apr 2019 17:08:31 -0400 Subject: [CMake] Using find_package fails to find related subprojects that are exported to the package registry Message-ID: Hi fellow CMake programmers! I've got a bit of a tricky situation and I wonder if anyone has ever dealt with this before. I am trying to configure a project that has a structure as follows myproject/ executable1/ <-- depends on common_lib1 my_common_libs/ common_lib1/ common_lib2/ Note: Before I begin - this is a legacy system and is MUCH larger than what I am showing here so restructuring the whole project is not really an option. Let me begin by describing the CMakeLists.txt structure. In myproject/CMakeLists.txt subdirectories are added as follows: file(GLOB entries *) foreach(entry ${entries}) if (IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt) add_subdirectory(${entry}) endif() endforeach() my_common_libs/CMakeLists.txt does the same... Then my_common_libs/common_lib1/CMakeLists.txt does what is necessary to define the library and export the target to the local package registry: add_library(common_lib1 ...) export(TARGETS common_lib1 NAMESPACE common_lib1:: FILE common_lib1-targets.cmake) file(COPY common_lib1-config.cmake DESTINATION ${CMAKE_CURRENT_BINARY_DIR}) export(PACKAGE common_lib1) my_common_libs/common_lib2/CMakeLists.txt does the same and both have "common_libx-config.cmake" files that properly load the corresponding "-targets.cmake" files. In executable1/CMakeLists.text I do what is necessary to find the package and use it: add_executable(executable1 ...) find_package(common_lib1 REQUIRED) <-- this is where I am having the problem target_link_libraries(executable1 common_lib1::common_lib1 ) Now this is where things get hairy... If I go into common_lib1 and manually build that first, it puts it in the package registry and then I can go to "executable1" and build that and it finds the package, and builds, and links fine. BUT... if I clean the project and then try to build it from the top level it immediately fails and says it can't locate the package "common_lib1". I understand I could probably replace the GLOB commands with explicit "add_subdirectory" calls and then carefully reorder all of the "add_subdirectory" commands to add things in dependency order, but that would be really tedious with how large the project is and is really not the way the whole rest of the system is done... It feels somewhat brittle because then I am essentially declaring the dependencies from outside of the modules themselves. Is there any way to force CMake to do all of the "export" commands up front to essentially initialize the package registry so it will be aware of common_lib1 when I compile from the "myproject" level? Or is there another solution I haven't even considered that could solve this same problem? Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhhjkl at gmail.com Wed Apr 10 20:08:45 2019 From: bhhjkl at gmail.com (SC Warrior) Date: Wed, 10 Apr 2019 17:08:45 -0700 Subject: [CMake] cmake build of LLVM: HAVE_CXX_ATOMICS_WITHOUT_LIB test failure Message-ID: I watched Chris Bieneman's talk about the transition of LLVM from autoconf to cmake and he raved about how friendly / vibrant the cmake community is so I thought I'd ask this here. I posted it to stack overflow but it's fairly involved so I hope it's cool that I post (my first) in this forum. I'm getting this failure trying to cross compile LLVM v3.7 (linux x64 -> Aarch64) w/ cmake: /clang++ -DHAVE_CXX_ATOMICS_WITHOUT_LIB -std=c++11 -rdynamic CMakeFiles/cmTC_82a21.dir/src.cxx.o -o cmTC_82a21 -lm -ldl && : ld.lld: error: undefined symbol: pthread_once referenced by cxa_exception_storage.cpp this is then followed by numerous other "undefined symbol: pthread_blah" errors in the CMakeError.log file. I have four questions: (1) What is this phase of operation that cmake is performing to determine the capabilities of the build environment / platform called ? (i.e. the configure-like phase that performs numerous small compilation tests to see if they succeed, looks to see if it can find header files in expected paths, etc). (2) It looks to me that including -lpthread as part of the test compilation line would fix this problem. (a) Is there a way to tell cmake to do that and (b) is that a smart approach to solving this problem ? Seems like if I could tell cmake to do this it would pass these tests. (3) The cmake command *seems* to succeed as it finishes with "Build files have been written to ...". What should I make of that when one of these pre-tests has a failure condition as cited above and reports "Configuring incomplete, errors occurred!". (4) I'm trying to get this cmake cross compile build to work with the stock LLVM v3.7 cmake files so I'm trying to control cmake using command line options only. This gets a little ugly and I'm wondering if there's a simple way to put all of these settings in a cmake file instead. One problem with that approach is that I'm not familiar with all of the targets in LLVM so if I were, to say, attempt to add libraries to targets to fix a linking problem, I wouldn't know offhand what targets to add them to. I'm hoping that in this case I can hit it with a bigger hammer and have them added everywhere with hopes of them being ignored if not used. I gratefully thank you for your patience and time reading all of that ^^^. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Apr 11 07:17:56 2019 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 11 Apr 2019 21:17:56 +1000 Subject: [CMake] linking FetchContent library In-Reply-To: <5e8ce7e7-1ec7-221d-7b3d-500e174d523c@numalliance.com> References: <87f30061-54c4-9479-a749-5c016506617a@numalliance.com> <5e8ce7e7-1ec7-221d-7b3d-500e174d523c@numalliance.com> Message-ID: (Please continue to CC the mailing list with replies) On Thu, Apr 11, 2019 at 4:22 PM St?phane Ancelot wrote: > > Le 10/04/2019 ? 23:03, Craig Scott a ?crit : > > > > On Thu, Apr 11, 2019 at 1:35 AM St?phane Ancelot > wrote: > >> Hi, >> >> are there any specific Cmake configurations to setup in projects when >> using fetchcontent. >> >> I am able to fetch and build a library but not able to link and include >> files of this library in another projects. >> >> include(FetchContent) >> >> FetchContent_Declare( >> jconcpp >> GIT_REPOSITORY https://github.com/joncol/jcon-cpp.git >> ) >> >> FetchContent_Populate(jconcpp) >> add_subdirectory(${jconcpp_SOURCE_DIR} ${jconcpp_BINARY_DIR}) >> > add_subdirectory(projA) > > Can you provide a complete minimal example which shows the problem? The > snippet above should bring jsoncpp into your main build, but without seeing > how you are trying to link to it's targets, it is hard to tell what the > problem could be. > > > fetchcontent is done in the main CMakeLists.txt > > I have a projA dir > > projA/CMakeLists.txt > > cmake_minimum_required(VERSION 3.10) > project(proja) > > add_executable(proja > proja.cpp) > > target_link_libraries(proja jconcpp) > There is no target in the jcon-cpp project by the name "jconcpp". The only library I can see in that project is one called "jcon". Note that you need to link against CMake targets, not against the dependency name used in the call to FetchContent_Declare(). -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsvargas at gmail.com Thu Apr 11 09:11:05 2019 From: rsvargas at gmail.com (Rafael Vargas) Date: Thu, 11 Apr 2019 10:11:05 -0300 Subject: [CMake] Using find_package fails to find related subprojects that are exported to the package registry In-Reply-To: References: Message-ID: I have a similarly organized project and it works without any of the find_package and the export commands. If you do include all of the CMakeFiles.txt files using add_directory, then it should be enough to: In my_common_libs/common_lib1/CMakeLists.txt: add_library(common_lib1 ...) In executable1/CMakeLists.text: add_executable(executable1 ...) target_link_libraries(executable1 common_lib1 ) This way you don't need to worry about ordering your add_directory commands as all the link dependencies will be ordered by CMake. -- Rafael Vargas Em qua, 10 de abr de 2019 ?s 18:08, Timothy Wrona escreveu: > Hi fellow CMake programmers! I've got a bit of a tricky situation and I > wonder if anyone has ever dealt with this before. > > I am trying to configure a project that has a structure as follows > > myproject/ > executable1/ <-- depends on common_lib1 > my_common_libs/ > common_lib1/ > common_lib2/ > > Note: Before I begin - this is a legacy system and is MUCH larger than > what I am showing here so restructuring the whole project is not really an > option. Let me begin by describing the CMakeLists.txt structure. > > In myproject/CMakeLists.txt subdirectories are added as follows: > > file(GLOB entries *) > foreach(entry ${entries}) > if (IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt) > add_subdirectory(${entry}) > endif() > endforeach() > > my_common_libs/CMakeLists.txt does the same... > > Then my_common_libs/common_lib1/CMakeLists.txt does what is necessary to > define the library and export the target to the local package registry: > > add_library(common_lib1 ...) > > export(TARGETS common_lib1 NAMESPACE common_lib1:: FILE > common_lib1-targets.cmake) > file(COPY common_lib1-config.cmake DESTINATION ${CMAKE_CURRENT_BINARY_DIR}) > export(PACKAGE common_lib1) > > my_common_libs/common_lib2/CMakeLists.txt does the same and both have > "common_libx-config.cmake" files that properly load the corresponding > "-targets.cmake" files. > > In executable1/CMakeLists.text I do what is necessary to find the package > and use it: > > add_executable(executable1 ...) > > find_package(common_lib1 REQUIRED) <-- this is where I am having the > problem > target_link_libraries(executable1 > common_lib1::common_lib1 > ) > > Now this is where things get hairy... > > If I go into common_lib1 and manually build that first, it puts it in the > package registry and then I can go to "executable1" and build that and it > finds the package, and builds, and links fine. > BUT... if I clean the project and then try to build it from the top level > it immediately fails and says it can't locate the package "common_lib1". > > I understand I could probably replace the GLOB commands with explicit > "add_subdirectory" calls and then carefully reorder all of the > "add_subdirectory" commands to add things in dependency order, but that > would be really tedious with how large the project is and is really not the > way the whole rest of the system is done... It feels somewhat brittle > because then I am essentially declaring the dependencies from outside of > the modules themselves. > > Is there any way to force CMake to do all of the "export" commands up > front to essentially initialize the package registry so it will be aware of > common_lib1 when I compile from the "myproject" level? Or is there another > solution I haven't even considered that could solve this same problem? > > Thanks, > Tim > -- > > 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 smeenai at fb.com Thu Apr 11 17:09:43 2019 From: smeenai at fb.com (Shoaib Meenai) Date: Thu, 11 Apr 2019 21:09:43 +0000 Subject: [CMake] cmake build of LLVM: HAVE_CXX_ATOMICS_WITHOUT_LIB test failure In-Reply-To: References: Message-ID: <3B7F51F5-65C3-4058-8614-F60A2926F52A@fb.com> llvm-dev at lists.llvm.org would also be a good place to ask questions about the LLVM build system :) 1. I believe it?s just called the configure phase. (There?s also the generation phase, where CMake actually generates the build system.) 2. How have you set up your cross-compilation? LLVM?s build system has logic to link pthread if needed, so I?m wondering why that?s failing. 3. LLVM?s cross-compilation runs a sub-configure for some native build components (e.g. TableGen) ? perhaps one of those sub-configures is succeeding but the main configure is failing? I?ve never seen the ?Build files have been written to? and ?Configuring incomplete, errors occurred? messages from the same configure. 4. You can use a CMake cache file ? see ?-C ? in https://cmake.org/cmake/help/latest/manual/cmake.1.html#options How come you?re working with LLVM 3.7, btw? That?s pretty old at this point, and newer versions will have improved the build system (and it?s also a lot easier to provide assistance for them). From: CMake on behalf of SC Warrior Date: Wednesday, April 10, 2019 at 5:09 PM To: "cmake at cmake.org" Subject: [CMake] cmake build of LLVM: HAVE_CXX_ATOMICS_WITHOUT_LIB test failure I watched Chris Bieneman's talk about the transition of LLVM from autoconf to cmake and he raved about how friendly / vibrant the cmake community is so I thought I'd ask this here. I posted it to stack overflow but it's fairly involved so I hope it's cool that I post (my first) in this forum. I'm getting this failure trying to cross compile LLVM v3.7 (linux x64 -> Aarch64) w/ cmake: /clang++ -DHAVE_CXX_ATOMICS_WITHOUT_LIB -std=c++11 -rdynamic CMakeFiles/cmTC_82a21.dir/src.cxx.o -o cmTC_82a21 -lm -ldl && : ld.lld: error: undefined symbol: pthread_once referenced by cxa_exception_storage.cpp this is then followed by numerous other "undefined symbol: pthread_blah" errors in the CMakeError.log file. I have four questions: (1) What is this phase of operation that cmake is performing to determine the capabilities of the build environment / platform called ? (i.e. the configure-like phase that performs numerous small compilation tests to see if they succeed, looks to see if it can find header files in expected paths, etc). (2) It looks to me that including -lpthread as part of the test compilation line would fix this problem. (a) Is there a way to tell cmake to do that and (b) is that a smart approach to solving this problem ? Seems like if I could tell cmake to do this it would pass these tests. (3) The cmake command seems to succeed as it finishes with "Build files have been written to ...". What should I make of that when one of these pre-tests has a failure condition as cited above and reports "Configuring incomplete, errors occurred!". (4) I'm trying to get this cmake cross compile build to work with the stock LLVM v3.7 cmake files so I'm trying to control cmake using command line options only. This gets a little ugly and I'm wondering if there's a simple way to put all of these settings in a cmake file instead. One problem with that approach is that I'm not familiar with all of the targets in LLVM so if I were, to say, attempt to add libraries to targets to fix a linking problem, I wouldn't know offhand what targets to add them to. I'm hoping that in this case I can hit it with a bigger hammer and have them added everywhere with hopes of them being ignored if not used. I gratefully thank you for your patience and time reading all of that ^^^. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Fri Apr 12 03:29:47 2019 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Fri, 12 Apr 2019 09:29:47 +0200 Subject: [CMake] AUTOMOC does not process headers in subdirectory of include/ In-Reply-To: <31aab211-889a-b536-fffa-77c1f2ebc336@emmenlauer.de> References: <31aab211-889a-b536-fffa-77c1f2ebc336@emmenlauer.de> Message-ID: <92c2107c-7eef-b014-65a7-1aa79564b934@emmenlauer.de> Anyone? On 10.04.19 14:48, Mario Emmenlauer wrote: > > Dear all, > > we have a problem that Qt moc is only called for headers in the > include directory of the project, not for subdirectories. Attached > is a minimal example. cmake should call moc to generate the moc- > sources in MyQtWidgets_autogen/include/bda/ folder. However the > sources are not generated. When I move the header out of the > subdirectory (from include/bda/CollapsibleDockWidget.hh to > include/CollapsibleDockWidget.hh) and fix the include path in the > source files, then moc works correctly. > > I think this is wrong, but I could not find explicit documentation > about how the headers and sources are set for moc (see [1]). > > Does cmake not respect the headers listed with add_library()? > Or is there something else I'm doing wrong? > > All the best, > > Mario Emmenlauer > > [1] https://cmake.org/cmake/help/latest/prop_tgt/AUTOMOC.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 robb at datalogics.com Fri Apr 12 10:16:44 2019 From: robb at datalogics.com (Rob Boehne) Date: Fri, 12 Apr 2019 14:16:44 +0000 Subject: [CMake] Make Visual Studio stop on error Message-ID: <0DCA3C72-88DC-47E7-A9ED-9751424E7B85@datalogics.com> All, We?re really loving CMake here! And we?ve been slowly figuring out how to make things work for our legacy C/C++ project. One improvement we want to make is to tell cmake to generate Visual Studio projects that stop building when a dependency target fails. Can something be set in the Visual Studio generator, or on the cmake ?build command line to do that? The reason is that when a target fails, it keeps compiling 8000 source files, and we have to search Jenkins (web-based) logs of stdout/stderr to find what actually failed. It also chews up resources with no benefit. Thanks, Rob [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: image001.png URL: From stephan.menzel at gmail.com Fri Apr 12 10:31:05 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Fri, 12 Apr 2019 15:31:05 +0100 Subject: [CMake] Support for Boost 1.70.0 Message-ID: Hello List, Boost 1.70.0 was just released and I'm integrating it into our projects. I notice FindBoost doesn't do the trick on Windows (MSVC141) anymore, on Linux / G++ it works fine. Here's what I do: set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) set(Boost_USE_DEBUG_LIBS OFF) set(Boost_USE_DEBUG_RUNTIME OFF) set(BOOST_INCLUDEDIR "${BOOST_ROOT}/include") set(BOOST_LIBRARYDIR "${BOOST_ROOT}/lib") find_package(Boost REQUIRED COMPONENTS system filesystem random chrono log date_time regex thread fiber exception program_options unit_test_framework ) It complains: Could not find the following static Boost libraries: boost_system boost_log boost_unit_test_framework Some (but not all) of the required Boost libraries were found. You may need to install these additional Boost libraries. Alternatively, set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Previous Boost versions worked. The libs are present as always and the same code works fine with 1.69. set(Boost_ADDITIONAL_VERSIONS "1.70.0") doesn't change anything as 1.70.0 appears to be already in the known versions struct in FindBoost. I have tested with CMake 3.13.4 and 3.14.1. Both fail. I have worked my way through the FindBoost module but can't figure out what causes those 3 libs to appear missing. They do appear in the Variables View, with their correct filenames. Everything seems to be fine but the error stops execution. When I remove those 3 libs from the list, linking against imported targets later breaks. Does anybody have the same issue upgrading? Is there a workaround perhaps? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Fri Apr 12 10:32:48 2019 From: frodak17 at gmail.com (frodak17) Date: Fri, 12 Apr 2019 10:32:48 -0400 Subject: [CMake] Make Visual Studio stop on error In-Reply-To: <0DCA3C72-88DC-47E7-A9ED-9751424E7B85@datalogics.com> References: <0DCA3C72-88DC-47E7-A9ED-9751424E7B85@datalogics.com> Message-ID: On Fri, Apr 12, 2019 at 10:16 AM Rob Boehne wrote: > All, > > > > We?re really loving CMake here! And we?ve been slowly figuring out how to > make things work for our legacy C/C++ project. > > One improvement we want to make is to tell cmake to generate Visual Studio > projects that stop building when a dependency target fails. > > Can something be set in the Visual Studio generator, or on the cmake > ?build command line to do that? > > > > The reason is that when a target fails, it keeps compiling 8000 source > files, and we have to search Jenkins (web-based) logs of stdout/stderr to > find what actually failed. It also chews up resources with no benefit. > > > > Thanks, > > > > Rob > > > It seems that Visual Studio requires an addon to support this kind of behaviour. https://marketplace.visualstudio.com/items?itemName=EinarEgilsson.StopOnFirstBuildError -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: not available URL: From mellery451 at gmail.com Fri Apr 12 11:02:44 2019 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 12 Apr 2019 08:02:44 -0700 Subject: [CMake] Support for Boost 1.70.0 In-Reply-To: References: Message-ID: whenever I use bleeding-edge boost, I try to grab the latest FindBoost: https://github.com/Kitware/CMake/commits/master/Modules/FindBoost.cmake ..in particular, you probably want https://github.com/Kitware/CMake/commit/266808c4130a0b40aed236381707462a9368a1eb#diff-555801259d7df67368f7deab1f9deacd which doesn?t look like it?s been merged to release yet. -Mike > On Apr 12, 2019, at 7:31 AM, Stephan Menzel wrote: > > Hello List, > > Boost 1.70.0 was just released and I'm integrating it into our projects. I notice FindBoost doesn't do the trick on Windows (MSVC141) anymore, on Linux / G++ it works fine. Here's what I do: > > set(Boost_USE_STATIC_LIBS ON) > set(Boost_USE_MULTITHREADED ON) > set(Boost_USE_STATIC_RUNTIME OFF) > set(Boost_USE_DEBUG_LIBS OFF) > set(Boost_USE_DEBUG_RUNTIME OFF) > > set(BOOST_INCLUDEDIR "${BOOST_ROOT}/include") > set(BOOST_LIBRARYDIR "${BOOST_ROOT}/lib") > > find_package(Boost REQUIRED > COMPONENTS > system > filesystem > random > chrono > log > date_time > regex > thread > fiber > exception > program_options > unit_test_framework > ) > > It complains: > Could not find the following static Boost libraries: > > boost_system > boost_log > boost_unit_test_framework > > Some (but not all) of the required Boost libraries were found. You may > need to install these additional Boost libraries. Alternatively, set > BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT > to the location of Boost. > > Previous Boost versions worked. The libs are present as always and the same code works fine with 1.69. > > set(Boost_ADDITIONAL_VERSIONS "1.70.0") doesn't change anything as 1.70.0 appears to be already in the known versions struct in FindBoost. > > I have tested with CMake 3.13.4 and 3.14.1. Both fail. > > I have worked my way through the FindBoost module but can't figure out what causes those 3 libs to appear missing. They do appear in the Variables View, with their correct filenames. Everything seems to be fine but the error stops execution. When I remove those 3 libs from the list, linking against imported targets later breaks. > > Does anybody have the same issue upgrading? Is there a workaround perhaps? > > Cheers, > Stephan > -- > > 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 stephan.menzel at gmail.com Fri Apr 12 11:18:36 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Fri, 12 Apr 2019 16:18:36 +0100 Subject: [CMake] Support for Boost 1.70.0 In-Reply-To: References: Message-ID: Hello Michael, thanks for your response. On Fri, Apr 12, 2019 at 4:02 PM Michael Ellery wrote: > whenever I use bleeding-edge boost, I try to grab the latest FindBoost: > https://github.com/Kitware/CMake/commits/master/Modules/FindBoost.cmake > > ..in particular, you probably want > https://github.com/Kitware/CMake/commit/266808c4130a0b40aed236381707462a9368a1eb#diff-555801259d7df67368f7deab1f9deacd > which doesn?t look like it?s been merged to release yet. > > I believe it has. I actually already tried those changes to no effect. It seems not identical to the 3.14.2 version but the changes to the dependency detection don't seem to be the issue. The problem is not so much that the dependencies among the imported targets are wrong, the problem is that 3 of those dependencies appear as NOT_FOUND, while they clearly are found. Still, FWIW I took the current commit and tried it, no change. Same error. This is very mysterious. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Apr 12 11:41:42 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 12 Apr 2019 11:41:42 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.2 available for download Message-ID: We are pleased to announce that CMake 3.14.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.14.2 since 3.14.1: Brad King (9): MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset ARMCC: Do not identify ARMClang as ARMCC IRSL: Fix discovery of VS 2019 v142 toolset redistributables Tests: Clarify hand-written cases in RunCMake.ParseImplicitIncludeInfo Tests: Teach RunCMake.ParseImplicitIncludeInfo to match output by regex Fix implicit include directory extraction for adaptive relative paths Xcode: Factor out duplicate source group code into lambda Xcode: Avoid mutating App Bundle targets during generation CMake 3.14.2 Julien Jomier (1): cmake-gui: Fix icon overlay on windows Regina Pfeifer (1): Modules/CTest: Fix SubmitURL mistersandman (1): cmake-gui: Fix theme on Windows with Qt >= 5.10 From mellery451 at gmail.com Fri Apr 12 11:48:45 2019 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 12 Apr 2019 08:48:45 -0700 Subject: [CMake] Support for Boost 1.70.0 In-Reply-To: References: Message-ID: <2DC56830-4C50-431B-ADCA-435C089D8672@gmail.com> oh, sorry I misunderstood. How did you build/install boost on windows? I?m not sure what ?Variable View? is?is that a CMake gui thing? Since it?s only complaining about a few libraries, is it possible that those three didn?t actually successfully build for one reason or another ? maybe check the stage directory for the expected lib files (I believe you?d be looking for the ? -mt-x64.lib? files?)? If those files really are present, then I agree it?s a strange problem. > On Apr 12, 2019, at 8:18 AM, Stephan Menzel wrote: > > Hello Michael, > > thanks for your response. > > On Fri, Apr 12, 2019 at 4:02 PM Michael Ellery wrote: > whenever I use bleeding-edge boost, I try to grab the latest FindBoost: https://github.com/Kitware/CMake/commits/master/Modules/FindBoost.cmake > > ..in particular, you probably want https://github.com/Kitware/CMake/commit/266808c4130a0b40aed236381707462a9368a1eb#diff-555801259d7df67368f7deab1f9deacd which doesn?t look like it?s been merged to release yet. > > > I believe it has. I actually already tried those changes to no effect. It seems not identical to the 3.14.2 version but the changes to the dependency detection don't seem to be the issue. The problem is not so much that the dependencies among the imported targets are wrong, the problem is that 3 of those dependencies appear as NOT_FOUND, while they clearly are found. > Still, FWIW I took the current commit and tried it, no change. Same error. This is very mysterious. > > Cheers, > Stephan > > > > -- > > 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 dzenan.zukic at kitware.com Fri Apr 12 12:09:37 2019 From: dzenan.zukic at kitware.com (Dzenan Zukic) Date: Fri, 12 Apr 2019 12:09:37 -0400 Subject: [CMake] Run a single test without parallelism Message-ID: Hi everybody, is there a way to prevent a test being run concurrently? I have a few tests which consume gigabytes of RAM, and when tests are being run in parallel (e.g. -j5) some of them non-deterministically fail due to memory allocation errors. Running most of the tests in parallel is an imperative because there are thousands of them. Regards, D?enan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Fri Apr 12 12:19:38 2019 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Fri, 12 Apr 2019 19:19:38 +0300 Subject: [CMake] Run a single test without parallelism In-Reply-To: References: Message-ID: Check RUN_SERIAL option for test https://cmake.org/cmake/help/v3.14/prop_test/RUN_SERIAL.html?highlight=run_serial ??, 12 ???. 2019 ?., 19:09 Dzenan Zukic via CMake : > Hi everybody, > > is there a way to prevent a test being run concurrently? I have a few > tests which consume gigabytes of RAM, and when tests are being run in > parallel (e.g. -j5) some of them non-deterministically fail due to memory > allocation errors. Running most of the tests in parallel is an imperative > because there are thousands of them. > > Regards, > D?enan > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Fri Apr 12 13:13:47 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Fri, 12 Apr 2019 19:13:47 +0200 Subject: [CMake] Support for Boost 1.70.0 In-Reply-To: <2DC56830-4C50-431B-ADCA-435C089D8672@gmail.com> References: <2DC56830-4C50-431B-ADCA-435C089D8672@gmail.com> Message-ID: > On 12. Apr 2019, at 17:48, Michael Ellery wrote: > > oh, sorry I misunderstood. How did you build/install boost on windows All ?normal? boostrap, build. With tagged filenames. Files look very much like I expect them to look. This will actually be the 50th boost version I?ll be using so I think I know the drill here. > I?m not sure what ?Variable View? is?is that a CMake gui thing? Yes. Didn?t know its official name. It does show all the libraries were found. > Since it?s only complaining about a few libraries, is it possible that those three didn?t actually successfully build for one reason or another ? maybe check the stage directory for the expected lib files (I believe you?d be looking for the ? -mt-x64.lib? files?)? If those files really are present, then I agree it?s a strange problem. I also double checked this a few times. Even rebuilt Boost and tried with different files. I guess the answer really lies in ?why those 3?? At first I thought it would be dependencies among the imported targets but I did depend on them directly. Also, the error is thrown before I create any target myself, so it must be something about detecting if the libs are found or not. I?m at a loss here. This is too strange. Cheers, Stephan From dzenan.zukic at kitware.com Fri Apr 12 15:28:58 2019 From: dzenan.zukic at kitware.com (Dzenan Zukic) Date: Fri, 12 Apr 2019 15:28:58 -0400 Subject: [CMake] Run a single test without parallelism In-Reply-To: References: Message-ID: Thank you, that's exactly what I was looking for! On Fri, Apr 12, 2019 at 12:19 PM Sergei Nikulov wrote: > Check RUN_SERIAL option for test > > > https://cmake.org/cmake/help/v3.14/prop_test/RUN_SERIAL.html?highlight=run_serial > > > ??, 12 ???. 2019 ?., 19:09 Dzenan Zukic via CMake : > >> Hi everybody, >> >> is there a way to prevent a test being run concurrently? I have a few >> tests which consume gigabytes of RAM, and when tests are being run in >> parallel (e.g. -j5) some of them non-deterministically fail due to >> memory allocation errors. Running most of the tests in parallel is an >> imperative because there are thousands of them. >> >> Regards, >> D?enan >> -- >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robb at datalogics.com Fri Apr 12 17:06:08 2019 From: robb at datalogics.com (Rob Boehne) Date: Fri, 12 Apr 2019 21:06:08 +0000 Subject: [CMake] Make Visual Studio stop on error In-Reply-To: References: <0DCA3C72-88DC-47E7-A9ED-9751424E7B85@datalogics.com> Message-ID: Thank you! But wow, I?m shocked that it can?t do this. It?s surprising that it?s not the default, let alone needs an add-on. From: CMake on behalf of frodak17 Date: Friday, April 12, 2019 at 9:33 AM Cc: "cmake at cmake.org" Subject: Re: [CMake] Make Visual Studio stop on error On Fri, Apr 12, 2019 at 10:16 AM Rob Boehne > wrote: All, We?re really loving CMake here! And we?ve been slowly figuring out how to make things work for our legacy C/C++ project. One improvement we want to make is to tell cmake to generate Visual Studio projects that stop building when a dependency target fails. Can something be set in the Visual Studio generator, or on the cmake ?build command line to do that? The reason is that when a target fails, it keeps compiling 8000 source files, and we have to search Jenkins (web-based) logs of stdout/stderr to find what actually failed. It also chews up resources with no benefit. Thanks, Rob It seems that Visual Studio requires an addon to support this kind of behaviour. https://marketplace.visualstudio.com/items?itemName=EinarEgilsson.StopOnFirstBuildError -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Apr 12 17:21:25 2019 From: d3ck0r at gmail.com (J Decker) Date: Fri, 12 Apr 2019 14:21:25 -0700 Subject: [CMake] Make Visual Studio stop on error In-Reply-To: References: <0DCA3C72-88DC-47E7-A9ED-9751424E7B85@datalogics.com> Message-ID: well you can just ctrl-break and stop it. a lot of times changing things doesn't cause everything to rebuild, so while fixing that small nuisance ... ya nevermind. On Fri, Apr 12, 2019 at 2:06 PM Rob Boehne wrote: > Thank you! > > But wow, I?m shocked that it can?t do this. It?s surprising that it?s not > the default, let alone needs an add-on. > > > > *From: *CMake on behalf of frodak17 < > frodak17 at gmail.com> > *Date: *Friday, April 12, 2019 at 9:33 AM > *Cc: *"cmake at cmake.org" > *Subject: *Re: [CMake] Make Visual Studio stop on error > > > > > > > > On Fri, Apr 12, 2019 at 10:16 AM Rob Boehne wrote: > > All, > > > > We?re really loving CMake here! And we?ve been slowly figuring out how to > make things work for our legacy C/C++ project. > > One improvement we want to make is to tell cmake to generate Visual Studio > projects that stop building when a dependency target fails. > > Can something be set in the Visual Studio generator, or on the cmake > ?build command line to do that? > > > > The reason is that when a target fails, it keeps compiling 8000 source > files, and we have to search Jenkins (web-based) logs of stdout/stderr to > find what actually failed. It also chews up resources with no benefit. > > > > Thanks, > > > > Rob > > > > > > It seems that Visual Studio requires an addon to support this kind of > behaviour. > > > > > https://marketplace.visualstudio.com/items?itemName=EinarEgilsson.StopOnFirstBuildError > > -- > > 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 bhhjkl at gmail.com Fri Apr 12 23:01:06 2019 From: bhhjkl at gmail.com (SC Warrior) Date: Fri, 12 Apr 2019 20:01:06 -0700 Subject: [CMake] cmake build of LLVM: HAVE_CXX_ATOMICS_WITHOUT_LIB test failure In-Reply-To: <3B7F51F5-65C3-4058-8614-F60A2926F52A@fb.com> References: <3B7F51F5-65C3-4058-8614-F60A2926F52A@fb.com> Message-ID: Thanks for your response Shoaib. I've got it building now. It required modifying the LLVM cmake scripts to include the libraries. 3.7 is a hard requirement. Cache file, great. Thanks! On Thu, Apr 11, 2019 at 2:09 PM Shoaib Meenai wrote: > llvm-dev at lists.llvm.org would also be a good place to ask questions about > the LLVM build system :) > > > > 1. I believe it?s just called the configure phase. (There?s also the > generation phase, where CMake actually generates the build system.) > 2. How have you set up your cross-compilation? LLVM?s build system has > logic to link pthread if needed, so I?m wondering why that?s failing. > 3. LLVM?s cross-compilation runs a sub-configure for some native build > components (e.g. TableGen) ? perhaps one of those sub-configures is > succeeding but the main configure is failing? I?ve never seen the ?Build > files have been written to? and ?Configuring incomplete, errors occurred? > messages from the same configure. > 4. You can use a CMake cache file ? see ?-C ? in > https://cmake.org/cmake/help/latest/manual/cmake.1.html#options > > > > How come you?re working with LLVM 3.7, btw? That?s pretty old at this > point, and newer versions will have improved the build system (and it?s > also a lot easier to provide assistance for them). > > > > *From: *CMake on behalf of SC Warrior < > bhhjkl at gmail.com> > *Date: *Wednesday, April 10, 2019 at 5:09 PM > *To: *"cmake at cmake.org" > *Subject: *[CMake] cmake build of LLVM: HAVE_CXX_ATOMICS_WITHOUT_LIB test > failure > > > > I watched Chris Bieneman's talk > about the transition of > LLVM from autoconf to cmake and he raved about how friendly / vibrant the > cmake community is so I thought I'd ask this here. I posted it to stack > overflow but it's fairly involved so I hope it's cool that I post (my > first) in this forum. > > > > I'm getting this failure trying to cross compile LLVM v3.7 (linux x64 -> > Aarch64) w/ cmake: > > /clang++ -DHAVE_CXX_ATOMICS_WITHOUT_LIB -std=c++11 -rdynamic CMakeFiles/cmTC_82a21.dir/src.cxx.o -o cmTC_82a21 -lm -ldl && : > > ld.lld: error: undefined symbol: pthread_once > > referenced by cxa_exception_storage.cpp > > this is then followed by numerous other "undefined symbol: pthread_blah" > errors in the CMakeError.log file. > > I have four questions: > > (1) What is this phase of operation that cmake is performing to determine > the capabilities of the build environment / platform called ? (i.e. the > configure-like phase that performs numerous small compilation tests to see > if they succeed, looks to see if it can find header files in expected > paths, etc). > > (2) It looks to me that including -lpthread as part of the test > compilation line would fix this problem. (a) Is there a way to tell cmake > to do that and (b) is that a smart approach to solving this problem ? Seems > like if I could tell cmake to do this it would pass these tests. > > (3) The cmake command *seems* to succeed as it finishes with "Build files > have been written to ...". What should I make of that when one of these > pre-tests has a failure condition as cited above and reports "Configuring > incomplete, errors occurred!". > > (4) I'm trying to get this cmake cross compile build to work with the > stock LLVM v3.7 cmake files so I'm trying to control cmake using command > line options only. This gets a little ugly and I'm wondering if there's a > simple way to put all of these settings in a cmake file instead. One > problem with that approach is that I'm not familiar with all of the targets > in LLVM so if I were, to say, attempt to add libraries to targets to fix a > linking problem, I wouldn't know offhand what targets to add them to. I'm > hoping that in this case I can hit it with a bigger hammer and have them > added everywhere with hopes of them being ignored if not used. > > I gratefully thank you for your patience and time reading all of that ^^^. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Sat Apr 13 06:04:37 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Sat, 13 Apr 2019 11:04:37 +0100 Subject: [CMake] Support for Boost 1.70.0 In-Reply-To: References: <2DC56830-4C50-431B-ADCA-435C089D8672@gmail.com> Message-ID: Hello List, On Fri, Apr 12, 2019 at 6:13 PM Stephan Menzel wrote: > > I guess the answer really lies in ?why those 3?? At first I thought it > would be dependencies among the imported targets but I did depend on them > directly. Also, the error is thrown before I create any target myself, so > it must be something about detecting if the libs are found or not. I?m at a > loss here. This is too strange. > A little update here. It is solved, please move along. It was my bad of course. I had focused on the actual libraries and went on and on debugging the module. Then it turned out it was the include dir. When copying it to it's final destination, somehow the copy command must have done only half of a job. Some include dirs were missing. This lead to the module finding the libs OK but some config headers, namely the ones listed in the missing list, were indeed not there. Took me so long to figure this out, since I was only looking at the actual library files and never suspected a half copied boost directory. An error message of the FindBoost module saying that the headers were missing would have been awesome though. Anyway, everything is fine now, thanks for your input! Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjwrona1992 at gmail.com Sat Apr 13 14:18:29 2019 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Sat, 13 Apr 2019 14:18:29 -0400 Subject: [CMake] Capturing command line arguments passed to CMake Message-ID: I am working on a CMake project that uses ExternalProject_Add to add an external dependency. The issue is, I need all of my command line arguments from my project to be propagated to the external project so it will build using the same build configuration and with the correct compiler settings. Is there a simple way to extract all of the command line arguments into a variable so I can simply pass them to ExternalProject_Add with the "CMAKE_ARGS" parameter? The only solution I have found so far is a function that parses the CMake Cache and extracts all of the variables with a help message that says "No help, variable specified on the command line." While this does work, it feels like a hacky workaround at best and seems like it may break in a future update of CMake if they decide to change the default cache help messages. Here is the code to make this hack work: get_cmake_property(CACHE_VARS CACHE_VARIABLES) foreach(CACHE_VAR ${CACHE_VARS}) get_property(CACHE_VAR_HELPSTRING CACHE ${CACHE_VAR} PROPERTY HELPSTRING) if(CACHE_VAR_HELPSTRING STREQUAL "No help, variable specified on the command line.") get_property(CACHE_VAR_TYPE CACHE ${CACHE_VAR} PROPERTY TYPE) if(CACHE_VAR_TYPE STREQUAL "UNINITIALIZED") set(CACHE_VAR_TYPE) else() set(CACHE_VAR_TYPE :${CACHE_VAR_TYPE}) endif() list(APPEND CMAKE_ARGS "-D${CACHE_VAR}${CACHE_VAR_TYPE}=${${CACHE_VAR}}") endif() endforeach() Is there any easy way to just get a list of all of the command line arguments without parsing the cache and filtering by help messages? This solution just really feels wrong... there must be a better way. Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Sun Apr 14 08:22:49 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Sun, 14 Apr 2019 14:22:49 +0200 Subject: [CMake] Ubuntu CMake Repository Now Available In-Reply-To: References: <1554491846.5439.45.camel@kitware.com> Message-ID: <2249824.Qm4x1PB58I@linux> Am Freitag, 5. April 2019, 22:15:37 CEST schrieb Sergei Nikulov: > It would be great to see officialy supported rpm repository for > CentOS/Fedora as well! The open build service [1] supports packaging for many distros, including Debian. The project for cmake is here [2]. You could ask the maintainers to add building cmake for CentOS/Fedora, too. Martin [1] https://openbuildservice.org/ [2] https://build.opensuse.org/package/show/devel:tools:building/cmake -- Cd wrttn wtht vwls s mch trsr. From jeff at 22ndtech.com Sun Apr 14 23:26:48 2019 From: jeff at 22ndtech.com (jeff at 22ndtech.com) Date: Sun, 14 Apr 2019 21:26:48 -0600 Subject: [CMake] How to generate a non-standard platform and non-standard project file with the Visual studio generator Message-ID: <005c01d4f33b$108aaa10$319ffe30$@22ndtech.com> Hi all, Do you have any suggestions for generation of a non-standard platform and project file from Visual Studio. I'm trying to generate a file compatible with the Magic Leap Visual Studio Extension. The first problem I have is that the platform is ML, not the standard x86 or x64. The next problem is that it is not a standard msbuild project file, but an nmake file. I've included the .vcxproj file from their simple OpenGL app sample below. Debug ML Release ML Debug x64 Release x64 {"$mlprojguid$"} $mlprojfile$ $mlprojkind$ $ml_mfit_extra_args$ True Makefile $platformtoolset$ Makefile $platformtoolset$ Makefile $platformtoolset$ Makefile $platformtoolset$ false false Project PropertySheet File $mlsdkpath$ $device_debug_certificate$ $ml_extra_build_options$ $device_debug_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -r -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -c -v --set-options=ide/visualstudio $(MLExtraBuildOption) $device_debug_preprocessor_defines$ $device_debug_include_paths$ $(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is. h $device_debug_packagefile$ $device_debug_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$device_debug_outputfile$ $(NMakeOutput) MLDebugger false true main true true $mlsdkpath$ $device_release_certificate$ $ml_extra_build_options$ $device_release_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -r -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -c -v --set-options=ide/visualstudio $(MLExtraBuildOption) $device_release_preprocessor_defines$ $device_release_include_paths$ $(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is. h $device_release_packagefile$ $device_release_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$device_release_outputfile$ $(NMakeOutput) MLDebugger false false true true $mlsdkpath$ $host_debug_certificate$ $ml_extra_build_options$ $host_debug_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -r -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -c -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) $host_debug_preprocessor_defines$ $host_debug_include_paths$ $host_debug_packagefile$ $host_debug_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$host_debug_outputfile$ WindowsLocalDebugger false true PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe vice\lib;$(MLSDK)\lib\win64 $(ProjectDir)\$ml_asset_folder$ $mlsdkpath$ $host_release_certificate$ $ml_extra_build_options$ $host_release_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -r -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -c -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) $host_release_preprocessor_defines$ $host_release_include_paths$ $host_release_packagefile$ $host_release_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$host_release_outputfile$ WindowsLocalDebugger false PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe vice\lib;$(MLSDK)\lib\win64 $(ProjectDir)\$ml_asset_folder$ $mlprojsources$ $mlprojincludes$ $mlprojresources$ $mlotherfiles$ I've been thinking about several alternatives. My first thought was to make modifications to the Visual Studio generator to support passing in the Platform and the options that I need but after reviewing the generator code, it looks like a monumental task, especially considering how many changes there are from a typical Visual Studio project file. The second thought I had was to post process the build file using CMake string replace or python. This seems like it would be much more manageable but before I went down that path I wanted to see if there is a more obvious way that is in better alignment with the CMake approach. I've even been asking myself if it makes sense to use CMake for this at all or is it just too far outside of the typical use cases. Any suggestions on the best path forward would be greatly appreciated. Thanks, Jeff From craig.scott at crascit.com Mon Apr 15 05:09:31 2019 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 15 Apr 2019 19:09:31 +1000 Subject: [CMake] Possible inconsistent behavior in target_sources() and CMake 3.14 In-Reply-To: References: Message-ID: On Wed, Apr 3, 2019 at 11:10 AM Michele Rosso wrote: > Hello, > according to the doc for CMake 3.14, target_sources() interprets relative > source file paths as being relative to the current source directory, i.e. > it should > prepend CMAKE_CURRENT_SOURCE_DIR to the relative paths given by the user. > However, this is not the case if the target and the sources are defined in > the same directory. > The docs say that target_sources() will *interpret* relative source file paths that way, but they do not state that it will prepend CMAKE_CURRENT_SOURCE_DIR. The docs for target_sources() only talk about how relative paths are interpreted. The docs for policy CMP0076 are a bit more explicit, but even they only say that target_sources() will convert the relative path to absolute *if the conditions also specified in those policy docs are met*. In the case where target_sources() is called in the same directory as where the target is defined, the target's SOURCE_DIR property and the CMAKE_CURRENT_SOURCE_DIR variable will hold the same value, so the relative path is not modified, as per the CMP0076 docs. > I attached a simple example to reproduce the issue. The structure of the > example is as follows: > > - cmake-bug/ > - CMakeLists.txt > - main.cpp > - foo/ > - CMakeLists.txt > - foo.H > - foo.cpp > - bar/ > - CMakeLists.txt > - bar.H > - bar.cpp > > Target "main.exe" is defined in the top-level CMakeLists.txt, while its > headers and sources are located in the the top-level directory > and in the sub-directories 'foo' and 'bar'. > After target_sources is used to include all the headers and sources, I > retrieve the "SOURCES" property for `main.exe`: all the sources and headers > but `main.cpp` are given the correct (absolute) path. > > Is this the intended behavior? If so, why should a source file located in > the same directory where the target is defined be treated any differently? > Yes, this is the intended behavior. There's no need to modify the path when target_sources() is called in the same directory as that in which the target is defined because the behavior is unambiguous and is the same whether CMP0076 is set to OLD or NEW. This is consistent with what you'd get if you had listed the sources directly in the add_executable() or add_library() call instead. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.tornblom at iar.com Mon Apr 15 07:51:54 2019 From: thomas.tornblom at iar.com (=?UTF-8?Q?Thomas_T=c3=b6rnblom?=) Date: Mon, 15 Apr 2019 13:51:54 +0200 Subject: [CMake] find_program(), how to handle executable suffix in a cross compilation environment? Message-ID: What is the proper way to handle the case where find_program() needs match "program-name" or "program-name.exe" depending on wether the host system is running a unix like OS or Windows? A project I'm looking at uses CMAKE_EXECUTABLE_SUFFIX for the target, so I assume that can't be used. A simple solution is to list both variants, but it adds clutter if the path contains variables and I'd like to know how others solve this. /Thomas -- *Thomas T?rnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom at iar.com Website: www.iar.com Twitter: www.twitter.com/iarsystems -------------- next part -------------- An HTML attachment was scrubbed... URL: From doenges at mvtec.com Mon Apr 15 09:24:37 2019 From: doenges at mvtec.com (Eric Doenges) Date: Mon, 15 Apr 2019 15:24:37 +0200 Subject: [CMake] Problem with try_compile() for iOS Message-ID: Hi, I'm currently testing CMake 3.14.2's iOS support with our build system and ran into a problem with try_compile() not finding the binary. Here is an example while trying to configure libjpeg-turbo 2.0.2 (I've shortened the paths to make this easier to read): --- SNIP --- -- Check size of size_t CMake Error at share/cmake-3.14/Modules/CheckTypeSize.cmake:120 (try_compile): ? Cannot copy output executable ??? '' ? to destination specified by COPY_FILE: 'libjpegturbo_library-ext-build/CMakeFiles/CheckTypeSize/SIZE_T.bin' ? Unable to find the executable at any of: ??? libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/cmTC_3f58e libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Debug/cmTC_3f58e libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Debug/cmTC_3f58e.app/cmTC_3f58e libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Development/cmTC_3f58e Call Stack (most recent call first): ? share/cmake-3.14/Modules/CheckTypeSize.cmake:247 (__check_type_size_impl) ? CMakeLists.txt:362 (check_type_size) --- SNIP --- The problem is that the binary created by try_compile is located at libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/cmTC_3f58e.app, where cmake doesn't look. This happens with both the Unix Makefile and Ninja generators (since I don't use the Xcode generator I have no idea if it works there). The following patch to cmake fixes the problem: --- SNIP --- diff -uNr cmake-3.14.2.orig/Source/cmCoreTryCompile.cxx cmake-3.14.2/Source/cmCoreTryCompile.cxx --- cmake-3.14.2.orig/Source/cmCoreTryCompile.cxx??? 2019-04-12 14:10:08.000000000 +0200 +++ cmake-3.14.2/Source/cmCoreTryCompile.cxx??? 2019-04-15 14:54:32.466161185 +0200 @@ -1040,8 +1040,12 @@ ?? } ?? searchDirs.emplace_back("/Debug"); ?#if defined(__APPLE__) -? std::string app = "/Debug/" + targetName + ".app"; +? // When building for Darwin, iOS, etc., the test program may be an .app +? // bundle, so look for those as well. +? std::string app = "/" + targetName + ".app"; ?? searchDirs.push_back(std::move(app)); +? std::string appd = "/Debug/" + targetName + ".app"; +? searchDirs.push_back(std::move(appd)); ?#endif ?? searchDirs.emplace_back("/Development"); --- SNIP --- So my question - is this a bug in CMake (the documentation says the Xcode generator is recommended, so I presume the other generators do not receive as much testing for iOS targets), or I am doing something fundamentally wrong ? With kind regards, Eric -- *Dr. Eric D?nges * Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrosso at lbl.gov Mon Apr 15 12:57:37 2019 From: mrosso at lbl.gov (Michele Rosso) Date: Mon, 15 Apr 2019 09:57:37 -0700 Subject: [CMake] Possible inconsistent behavior in target_sources() and CMake 3.14 In-Reply-To: References: Message-ID: Hi Craig, thanks for the clarification. Best, Michele On Mon, Apr 15, 2019 at 2:09 AM Craig Scott wrote: > > > On Wed, Apr 3, 2019 at 11:10 AM Michele Rosso wrote: > >> Hello, >> according to the doc for CMake 3.14, target_sources() interprets relative >> source file paths as being relative to the current source directory, i.e. >> it should >> prepend CMAKE_CURRENT_SOURCE_DIR to the relative paths given by the user. >> However, this is not the case if the target and the sources are defined in >> the same directory. >> > > The docs say that target_sources() will *interpret* relative source file > paths that way, but they do not state that it will prepend > CMAKE_CURRENT_SOURCE_DIR. The docs for target_sources() only talk about how > relative paths are interpreted. The docs for policy CMP0076 are a bit more > explicit, but even they only say that target_sources() will convert the > relative path to absolute *if the conditions also specified in those > policy docs are met*. In the case where target_sources() is called in the > same directory as where the target is defined, the target's SOURCE_DIR > property and the CMAKE_CURRENT_SOURCE_DIR variable will hold the same > value, so the relative path is not modified, as per the CMP0076 docs. > > > >> I attached a simple example to reproduce the issue. The structure of the >> example is as follows: >> >> - cmake-bug/ >> - CMakeLists.txt >> - main.cpp >> - foo/ >> - CMakeLists.txt >> - foo.H >> - foo.cpp >> - bar/ >> - CMakeLists.txt >> - bar.H >> - bar.cpp >> >> Target "main.exe" is defined in the top-level CMakeLists.txt, while its >> headers and sources are located in the the top-level directory >> and in the sub-directories 'foo' and 'bar'. >> After target_sources is used to include all the headers and sources, I >> retrieve the "SOURCES" property for `main.exe`: all the sources and headers >> but `main.cpp` are given the correct (absolute) path. >> >> Is this the intended behavior? If so, why should a source file located in >> the same directory where the target is defined be treated any differently? >> > > Yes, this is the intended behavior. There's no need to modify the path > when target_sources() is called in the same directory as that in which the > target is defined because the behavior is unambiguous and is the same > whether CMP0076 is set to OLD or NEW. This is consistent with what you'd > get if you had listed the sources directly in the add_executable() or > add_library() call instead. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > Get the hand-book for every CMake user: Professional CMake: A Practical > Guide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Apr 15 19:01:12 2019 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 16 Apr 2019 09:01:12 +1000 Subject: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries found Message-ID: Has anyone else got issues using Boost 1.70 in their code. I'm using CMake 3.14.2 I have done the usual build/install of Boost in linux and everything seems to be installed Ok in /usr/local/include and /usr/local lib. The problem is the no linker libraries are being found. I use this in my CMakeLists.txt fle: #---- find_package(Boost *1.70.0 *EXACT REQUIRED COMPONENTS date_time filesystem regex serialization system thread iostreams ) #--- I reinstalled Boost 1.69 and changed to *1.69.0* in find_package and everything builds OK. *Boost 1.69* When using 1.69 in CMakeLists.txt file I get expected entries like: //Boost date_time library (debug) Boost_DATE_TIME_LIBRARY_DEBUG:FILEPATH=/usr/local/lib/libboost_date_time.so In build.ninja all the requested linker libraries are there e.g. /usr/local/lib/libboost_date_time.so *Boost 1.70* When using Boost 1.70 all I get in the CMakeLists.txt file are entries like: //The directory containing a CMake configuration file for boost_date_time. boost_date_time_DIR:PATH=/usr/local/lib/cmake/boost_date_time-1.70.0 In build.ninja no linker libraries are listed. Everything seems in order in /usr/local/lib: -------------------------------------- -rw-r--r-- 1 root root 160618 Apr 16 07:46 libboost_date_time.a lrwxrwxrwx 1 root root 28 Apr 16 08:08 libboost_date_time.so -> libboost_date_t ime.so.1.70.0 lrwxrwxrwx 1 root root 28 Apr 16 08:08 libboost_date_time.so.1 -> libboost_date _time.so.1.70.0 -rwxr-xr-x 1 root root 103672 Apr 16 07:47 libboost_date_time.so.1.69.0 lrwxrwxrwx 1 root root 28 Apr 16 08:08 libboost_date_time.so.1.70 -> libboost_d ate_time.so.1.70.0 -rwxr-xr-x 1 root root 103672 Apr 16 08:08 libboost_date_time.so.1.70.0 --------------------------- It is also not possible to build in Windows using VS2019 and Boost 1.70. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Mon Apr 15 19:10:44 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 16 Apr 2019 01:10:44 +0200 Subject: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries found In-Reply-To: References: Message-ID: On Tue, 16 Apr 2019 at 01:01, Andrew Maclean wrote: > > In build.ninja all the requested linker libraries are there e.g. /usr/local/lib/libboost_date_time.so> > Boost 1.70 > When using Boost 1.70 all I get in the CMakeLists.txt file are entries like: > //The directory containing a CMake configuration file for boost_date_time. > boost_date_time_DIR:PATH=/usr/local/lib/cmake/boost_date_time-1.70.0 Installation of Boost 1.70 generates and deploys a brand new BoostConfig.cmake machinery which is still being tested. Try setting -DBoost_NO_BOOST_CMAKE=ON to get the old FindBoost.cmake behaviour https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L238 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From sergey.nikulov at gmail.com Tue Apr 16 08:07:14 2019 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Tue, 16 Apr 2019 15:07:14 +0300 Subject: [CMake] ctest // fixtures and --repeat-until-fail Message-ID: Hello All, Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with --repeat-until-fail option? My expectation, if I requesting a test run for example 10 times, the sequence should be as follows: fixture_setup, then test, then fixture_cleanup repeats 10 times But in practice, I've got following sequence 1. fixture_setup runs 10 times 2. test runs 10 times 3. fixture_cleanup runs 10 times Is it expected behavior? I'm using ctest version 3.14.2 Thank you in advance. -- Best Regards, Sergei Nikulov From craig.scott at crascit.com Tue Apr 16 08:55:37 2019 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 16 Apr 2019 22:55:37 +1000 Subject: [CMake] ctest // fixtures and --repeat-until-fail In-Reply-To: References: Message-ID: On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov wrote: > Hello All, > > Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with > --repeat-until-fail option? > > My expectation, if I requesting a test run for example 10 times, the > sequence should be as follows: > > fixture_setup, then test, then fixture_cleanup repeats 10 times > > But in practice, I've got following sequence > > 1. fixture_setup runs 10 times > 2. test runs 10 times > 3. fixture_cleanup runs 10 times > > Is it expected behavior? > I'm using ctest version 3.14.2 > The documentation for the --repeat-until-fail option says "Require each test to run times without failing in order to pass". A fixture setup or cleanup test is still a test, so they will also be run times. The logic that implements repeating tests sets up a counter on each test and it runs that test times before marking that test as complete. This is why you see fixture_setup run 10 times, then test runs 10 times and lastly fixture_cleanup runs 10 times. Whenever I've wanted to use --repeat-until-fail (admittedly not all that common for me), I'm generally only interested in repeatedly running one particular test. For that case, I would typically run the test once with fixture cleanups disabled (i.e. use a command line "ctest -FC . -R myFlakeyTest"). I can then run ctest again for just my flaky test with all fixtures disabled (e.g. "ctest -FA . -R myFlakeyTest --repeat-until-fail 10"). This strategy won't work for everyone's situation, but it has been effective for me. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Tue Apr 16 09:35:52 2019 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Tue, 16 Apr 2019 16:35:52 +0300 Subject: [CMake] ctest // fixtures and --repeat-until-fail In-Reply-To: References: Message-ID: > > On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov wrote: >> >> Hello All, >> >> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with >> --repeat-until-fail option? >> >> My expectation, if I requesting a test run for example 10 times, the >> sequence should be as follows: >> >> fixture_setup, then test, then fixture_cleanup repeats 10 times >> >> But in practice, I've got following sequence >> >> 1. fixture_setup runs 10 times >> 2. test runs 10 times >> 3. fixture_cleanup runs 10 times >> >> Is it expected behavior? >> I'm using ctest version 3.14.2 > > > The documentation for the --repeat-until-fail option says "Require each test to run times without failing in order to pass". A fixture setup or cleanup test is still a test, so they will also be run times. The logic that implements repeating tests sets up a counter on each test and it runs that test times before marking that test as complete. This is why you see fixture_setup run 10 times, then test runs 10 times and lastly fixture_cleanup runs 10 times. > I understand that fixture is still a test. To achieve repeatable behavior -R "test_continues_*" is enough. But if it calls FIXTURE why not apply the specific behavior as expected from fixture (init/teardown)? -- Best Regards, Sergei Nikulov From dustyn at blasig.us Tue Apr 16 11:02:01 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Tue, 16 Apr 2019 10:02:01 -0500 Subject: [CMake] CXX and CUDACXX Message-ID: Hi All, I'd like to understand the expectations with CMake 3.12+ with the following setup. project(foo LANGUAGES CXX CUDA) By default, should the CUDACXX compiler be using the found compiler for CXX for host-side compilation? What I'm seeing is that host-side compilation for CUDA is not passing -ccbin to NVCC or setting up the environment in a way that nvcc will use the CXX configured compiler but rather just using the c++ it finds on PATH. Is there a best practice for telling the CUDA language to use the CXX settings for host-side compilation? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From s-morris at n-eos.com Tue Apr 16 12:36:22 2019 From: s-morris at n-eos.com (Stephen Morris) Date: Tue, 16 Apr 2019 16:36:22 +0000 Subject: [CMake] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc. Message-ID: I?m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND properties to facilitate debugging in a CMake-generated Visual Studio project file (in my case Visual Studio 2013). Everything else in my configuration works except this? I?ve noted from ?regular? Visual Studio project files (i.e. ones not generated from CMake that, in the ?Configuration Properties/Debugging? dialog, the ?Command? and ?Working Directory? fields are populated by default with $(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I have: set_target_properties(myApplication PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)" VS_DEBUGGER_COMMAND "$(TargetPath)" VS_DEBUGGER_ENVIRONMENT "%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin") [In fact I've tried this with and without the quotes around $(TargetDir) and $(TargetPath) and the result is the same each time; they're absolutely necessary around the path.] What happens is that I then build the application, go to the ?Configuration Properties/Debugging? dialog and verify that it looks exactly the same as a normal project file, with $(TargetDir) and $(TargetPath) appearing exactly where they should do. It doesn't work though; when I try to debug I get a message saying "Unable to start debugging. Check your debugger settings..." So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type them in again exactly as before: and then it works perfectly. What am I doing wrong? From robert.maynard at kitware.com Tue Apr 16 14:09:26 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 16 Apr 2019 14:09:26 -0400 Subject: [CMake] CXX and CUDACXX In-Reply-To: References: Message-ID: The default implementation is to defer to CUDA for selecting what ever host compiler it would like. To make sure that CMake uses the same CXX and CUDACXX compiler you will need to explicitly state that either through the CUDAHOSTCXX env variable ( https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. From dustyn at blasig.us Tue Apr 16 14:23:55 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Tue, 16 Apr 2019 13:23:55 -0500 Subject: [CMake] CXX and CUDACXX In-Reply-To: References: Message-ID: Thx for the info. Since CXX and CUDA are defined together in the project() command, I don't see a way to inject code to use the CXX compiler if no CUDAHOSTCXX or CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I tried moving CUDA out to an enable_language(CUDA) call instead so I could set those variables between project(foo LANGUAGES CXX) and enable_language(CUDA), but I'm seeing other issues with that approach. Any other suggestions? If not, we'll just wrap our cmake invocation in a script to help setup the environment properly for now. Thx! On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard wrote: > The default implementation is to defer to CUDA for selecting what > ever host compiler it would like. To make sure that CMake uses the > same CXX and CUDACXX compiler you will need to explicitly state that > either through the CUDAHOSTCXX env variable ( > https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with > CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Apr 16 14:43:49 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 16 Apr 2019 14:43:49 -0400 Subject: [CMake] CXX and CUDACXX In-Reply-To: References: Message-ID: I don't have any other suggestions. In general I recommend the script approach or using enable_language(CUDA). The enable_language approach should work, so I am curious what other issues you are seeing. On Tue, Apr 16, 2019 at 2:24 PM Dustyn Blasig wrote: > > Thx for the info. > > Since CXX and CUDA are defined together in the project() command, I don't see a way to inject code to use the CXX compiler if no CUDAHOSTCXX or CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I tried moving CUDA out to an enable_language(CUDA) call instead so I could set those variables between project(foo LANGUAGES CXX) and enable_language(CUDA), but I'm seeing other issues with that approach. > > Any other suggestions? If not, we'll just wrap our cmake invocation in a script to help setup the environment properly for now. > > Thx! > > On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard wrote: >> >> The default implementation is to defer to CUDA for selecting what >> ever host compiler it would like. To make sure that CMake uses the >> same CXX and CUDACXX compiler you will need to explicitly state that >> either through the CUDAHOSTCXX env variable ( >> https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with >> CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. From dustyn at blasig.us Tue Apr 16 15:37:20 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Tue, 16 Apr 2019 14:37:20 -0500 Subject: [CMake] Linked Imported Library in Visual Studio Showing NOTFOUND Message-ID: Hi All, I'm trying to debug an issues where an imported shared library is showing up in the linker command as not found, but within the CMake generation the target seems to exist. # CMakeLists.txt #################### include(bar.cmake) add_library(foo SHARED) if(TARGET bar) target_link_libraries(foo PUBLIC bar) endif() # bar.cmake ####################### add_library(bar SHARED IMPORTED) ... On Linux, the link command contains the correct *-L* and *-lbar* options. However, on Windows (Visual Studio) the linker command has "bar-NOTFOUND" instead of bar.lib as it should, even though bar should only be added as a dependency *if* it exists. How can I debug why this would happen? Is there a way to have CMake dump more information about that target? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Apr 16 18:01:00 2019 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 17 Apr 2019 08:01:00 +1000 Subject: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries found (Mateusz Loskot) In-Reply-To: References: Message-ID: Thank you so much, this works perfectly. > > ---------- Forwarded message ---------- > From: Mateusz Loskot > To: cmake at cmake.org > Cc: > Bcc: > Date: Tue, 16 Apr 2019 01:10:44 +0200 > Subject: Re: [CMake] Boost 1.70.0 -- FindBoost issues? No linker libraries > found > On Tue, 16 Apr 2019 at 01:01, Andrew Maclean > wrote: > > > > In build.ninja all the requested linker libraries are there e.g. > /usr/local/lib/libboost_date_time.so> > > Boost 1.70 > > When using Boost 1.70 all I get in the CMakeLists.txt file are entries > like: > > //The directory containing a CMake configuration file for > boost_date_time. > > boost_date_time_DIR:PATH=/usr/local/lib/cmake/boost_date_time-1.70.0 > > Installation of Boost 1.70 generates and deploys a brand new > BoostConfig.cmake > machinery which is still being tested. > > Try setting -DBoost_NO_BOOST_CMAKE=ON to get the old FindBoost.cmake > behaviour > https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L238 > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at 22ndtech.com Tue Apr 16 23:28:58 2019 From: jeff at 22ndtech.com (jeff at 22ndtech.com) Date: Tue, 16 Apr 2019 21:28:58 -0600 Subject: [CMake] How to generate a non-standard platform and non-standard project file with the Visual studio generator In-Reply-To: <005c01d4f33b$108aaa10$319ffe30$@22ndtech.com> References: <005c01d4f33b$108aaa10$319ffe30$@22ndtech.com> Message-ID: <000301d4f4cd$b40f6d90$1c2e48b0$@22ndtech.com> OK, no response yet. I'm not sure if that means this is a problem that isn't interesting to most or if it is a good hard problem that no one knows how to solve. Thinking a little more, I'm starting to lean toward a solution where I have a build_src folder where I put something like the sample .vcxproj file that I pasted in my first e-mail. I can update the file substituting CMake variables for some of the information that needs to be updated and use configure_package_config_file() to replace the data according to the execution of cmake against the current CMakeLists.txt file. Then, maybe I could copy the output file over the standard cmake process generated .vcxproj file as a post build step. Not sure if this would work, particularly the bit about copying over the standard .vcxproj file, but one way to find out, right? This is the approach I'm going to attempt unless anyone has a better suggestion. Trying not to beg for help here. ? -----Original Message----- From: CMake On Behalf Of jeff at 22ndtech.com Sent: Sunday, April 14, 2019 9:27 PM To: cmake at cmake.org Subject: [CMake] How to generate a non-standard platform and non-standard project file with the Visual studio generator Hi all, Do you have any suggestions for generation of a non-standard platform and project file from Visual Studio. I'm trying to generate a file compatible with the Magic Leap Visual Studio Extension. The first problem I have is that the platform is ML, not the standard x86 or x64. The next problem is that it is not a standard msbuild project file, but an nmake file. I've included the .vcxproj file from their simple OpenGL app sample below. Debug ML Release ML Debug x64 Release x64 {"$mlprojguid$"} $mlprojfile$ $mlprojkind$ $ml_mfit_extra_args$ True Makefile $platformtoolset$ Makefile $platformtoolset$ Makefile $platformtoolset$ Makefile $platformtoolset$ false false Project PropertySheet File $mlsdkpath$ $device_debug_certificate$ $ml_extra_build_options$ $device_debug_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -r -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_debug -c -v --set-options=ide/visualstudio $(MLExtraBuildOption) $device_debug_preprocessor_defines$ $device_debug_include_paths$ $(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is. h $device_debug_packagefile$ $device_debug_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$device_debug_outputfile$ $(NMakeOutput) MLDebugger false true main true true $mlsdkpath$ $device_release_certificate$ $ml_extra_build_options$ $device_release_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -r -v --set-options=ide/visualstudio $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t device_release -c -v --set-options=ide/visualstudio $(MLExtraBuildOption) $device_release_preprocessor_defines$ $device_release_include_paths$ $(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is. h $device_release_packagefile$ $device_release_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$device_release_outputfile$ $(NMakeOutput) MLDebugger false false true true $mlsdkpath$ $host_debug_certificate$ $ml_extra_build_options$ $host_debug_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -r -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_debug -c -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) $host_debug_preprocessor_defines$ $host_debug_include_paths$ $host_debug_packagefile$ $host_debug_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$host_debug_outputfile$ WindowsLocalDebugger false true PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe vice\lib;$(MLSDK)\lib\win64 $(ProjectDir)\$ml_asset_folder$ $mlsdkpath$ $host_release_certificate$ $ml_extra_build_options$ $host_release_full_spec$ $(MLSDK);$(PATH) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -r -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t msvc-$msvcversion$_release -c -v VCDIR="$(VCInstallDir) $(MLExtraBuildOption) $host_release_preprocessor_defines$ $host_release_include_paths$ $host_release_packagefile$ $host_release_outputdir$ $(ProjectDir)\$(IntDir) $(IntDir)\$host_release_outputfile$ WindowsLocalDebugger false PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe vice\lib;$(MLSDK)\lib\win64 $(ProjectDir)\$ml_asset_folder$ $mlprojsources$ $mlprojincludes$ $mlprojresources$ $mlotherfiles$ I've been thinking about several alternatives. My first thought was to make modifications to the Visual Studio generator to support passing in the Platform and the options that I need but after reviewing the generator code, it looks like a monumental task, especially considering how many changes there are from a typical Visual Studio project file. The second thought I had was to post process the build file using CMake string replace or python. This seems like it would be much more manageable but before I went down that path I wanted to see if there is a more obvious way that is in better alignment with the CMake approach. I've even been asking myself if it makes sense to use CMake for this at all or is it just too far outside of the typical use cases. Any suggestions on the best path forward would be greatly appreciated. Thanks, Jeff -- 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 s-morris at n-eos.com Wed Apr 17 04:34:10 2019 From: s-morris at n-eos.com (Stephen Morris) Date: Wed, 17 Apr 2019 08:34:10 +0000 Subject: [CMake] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc. In-Reply-To: References: Message-ID: It turns out that the solution is to replace "$(TargetPath)" and "$(TargetDir)" with the CMake generator expressions "`$`" and "`$`", respectively, viz: set_target_properties(myApplication PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$" VS_DEBUGGER_COMMAND "$" VS_DEBUGGER_ENVIRONMENT "PATH=%PATH%;${CMAKE_PREFIX_PATH}/bin") ________________________________ From: Stephen Morris Sent: 16 April 2019 17:36 To: cmake at cmake.org Subject: Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc. I?m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND properties to facilitate debugging in a CMake-generated Visual Studio project file (in my case Visual Studio 2013). Everything else in my configuration works except this? I?ve noted from ?regular? Visual Studio project files (i.e. ones not generated from CMake that, in the ?Configuration Properties/Debugging? dialog, the ?Command? and ?Working Directory? fields are populated by default with $(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I have: set_target_properties(myApplication PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)" VS_DEBUGGER_COMMAND "$(TargetPath)" VS_DEBUGGER_ENVIRONMENT "%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin") [In fact I've tried this with and without the quotes around $(TargetDir) and $(TargetPath) and the result is the same each time; they're absolutely necessary around the path.] What happens is that I then build the application, go to the ?Configuration Properties/Debugging? dialog and verify that it looks exactly the same as a normal project file, with $(TargetDir) and $(TargetPath) appearing exactly where they should do. It doesn't work though; when I try to debug I get a message saying "Unable to start debugging. Check your debugger settings..." So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type them in again exactly as before: and then it works perfectly. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Apr 17 07:50:08 2019 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 17 Apr 2019 13:50:08 +0200 Subject: [CMake] Linked Imported Library in Visual Studio Showing NOTFOUND In-Reply-To: References: Message-ID: Hi Dustyn, ELF platforms link against .so files, but Windows links against import libraries (.lib files) assocaited with DLLs. Does the target 'bar' have the IMPORTED_IMPLIB property set up correctly? (See https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_IMPLIB.html ) Petr On Tue, 16 Apr 2019 at 21:37, Dustyn Blasig wrote: > Hi All, > > I'm trying to debug an issues where an imported shared library is showing > up in the linker command as not found, but within the CMake generation the > target seems to exist. > > # CMakeLists.txt #################### > > include(bar.cmake) > > add_library(foo SHARED) > > if(TARGET bar) > target_link_libraries(foo PUBLIC bar) > endif() > > # bar.cmake ####################### > > add_library(bar SHARED IMPORTED) > > ... > > > On Linux, the link command contains the correct *-L* and *-lbar* > options. However, on Windows (Visual Studio) the linker command has > "bar-NOTFOUND" instead of bar.lib as it should, even though bar should only > be added as a dependency *if* it exists. > > How can I debug why this would happen? Is there a way to have CMake dump > more information about that target? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustyn at blasig.us Wed Apr 17 11:25:43 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Wed, 17 Apr 2019 10:25:43 -0500 Subject: [CMake] Linked Imported Library in Visual Studio Showing NOTFOUND In-Reply-To: References: Message-ID: Ah, thanks, that was it. So when I use find_library(), it finds the .lib portion on Windows. Is there a way to find the .dll portion as well? Also, if I change the library type to STATIC on Windows, that seems to have the same effect on the linkers command line as leaving it as SHARED but changing the library property from IMPORTED_LOCATION to IMPORTED_IMPLIB. Are there other differences? If someone has a nice online example of a "best practice" for fining the .dll/.lib/.so portions and setting them up, I'd love to take a look. Thx! On Wed, Apr 17, 2019 at 6:50 AM Petr Kmoch wrote: > Hi Dustyn, > > ELF platforms link against .so files, but Windows links against import > libraries (.lib files) assocaited with DLLs. Does the target 'bar' have the > IMPORTED_IMPLIB property set up correctly? (See > https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_IMPLIB.html ) > > Petr > > On Tue, 16 Apr 2019 at 21:37, Dustyn Blasig wrote: > >> Hi All, >> >> I'm trying to debug an issues where an imported shared library is showing >> up in the linker command as not found, but within the CMake generation the >> target seems to exist. >> >> # CMakeLists.txt #################### >> >> include(bar.cmake) >> >> add_library(foo SHARED) >> >> if(TARGET bar) >> target_link_libraries(foo PUBLIC bar) >> endif() >> >> # bar.cmake ####################### >> >> add_library(bar SHARED IMPORTED) >> >> ... >> >> >> On Linux, the link command contains the correct *-L* and >> *-lbar* options. However, on Windows (Visual Studio) the linker command >> has "bar-NOTFOUND" instead of bar.lib as it should, even though bar should >> only be added as a dependency *if* it exists. >> >> How can I debug why this would happen? Is there a way to have CMake dump >> more information about that target? >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Mon Apr 22 09:45:20 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Mon, 22 Apr 2019 13:45:20 +0000 Subject: [CMake] Need help with CMake error "CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 file INSTALL cannot find "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include"." Message-ID: As the title says, I have this error when trying to build INSTALL.vcxproj in LLVM.sln using Visual Studio Community 2019: " 522>CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 (file): 522> file INSTALL cannot find? 522> "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include".? 522>Call Stack (most recent call first):? 522> tools/clang/lib/cmake_install.cmake:37 (include)? 522> tools/clang/cmake_install.cmake:54 (include)? 522> tools/cmake_install.cmake:43 (include)? 522> cmake_install.cmake:64 (include)? 522>? 522>? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: The command "setlocal? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmErrorLevel? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: exit /b %1? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :VCEnd" exited with code 1.? 522>Done building project "INSTALL.vcxproj" -- FAILED. " Everything else was built successfully, it's just this one project that it can't build. I checked in the file path it mentioned and I can see the "include" folder in there. So there's probably something I need to change in cmake_install.cmake. I've attached the file to this message. I hope someone will help me change it such that this will work. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_install.cmake Type: application/octet-stream Size: 3129 bytes Desc: cmake_install.cmake URL: From robert.maynard at kitware.com Mon Apr 22 10:50:36 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 22 Apr 2019 10:50:36 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.3 available for download Message-ID: We are pleased to announce that CMake 3.14.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.14.3 since 3.14.2: Ben Boeckel (1): FindOpenGL: look for GLVND libraries with a libglvnd suffix Brad King (4): FindBoost: Add support for MSVC toolset version 14.2 IRSL: Update redist directory for VS 2019 update 1 VS: Provide the default platform name to project code CMake 3.14.3 Christian Pfeiffer (1): FindQt3: Restore missing lib and bin path suffixes Rolf Eike Beer (1): FindBoost: Fix detection with version suffixes on Gentoo From d3ck0r at gmail.com Mon Apr 22 18:50:31 2019 From: d3ck0r at gmail.com (J Decker) Date: Mon, 22 Apr 2019 15:50:31 -0700 Subject: [CMake] Add Custom Command after strip Message-ID: I'm trying to use MingW64-x86 to compile this project. I'm using MingW Makefiles as the generator. Some of the executable files need 'mt.exe' run to add a manifest to them (on windows). The MT.exe breaks the .exe for strip such that it says 'file has been truncated' and the build stops. Strip is run against the executable during release builds... The documentation of course saying POST_BUILD on the add_custom_command says 'after all the build steps' but apparently strip is some sort of post-build thing itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeenai at fb.com Mon Apr 22 19:09:17 2019 From: smeenai at fb.com (Shoaib Meenai) Date: Mon, 22 Apr 2019 23:09:17 +0000 Subject: [CMake] Need help with CMake error "CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 file INSTALL cannot find "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include"." Message-ID: You're probably running into https://reviews.llvm.org/D58537#inline-532492. This is an LLVM issue, not a CMake issue. From: CMake on behalf of Osman Zakir Date: Monday, April 22, 2019 at 6:45 AM To: "cmake at cmake.org" Subject: [CMake] Need help with CMake error "CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 file INSTALL cannot find "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include"." As the title says, I have this error when trying to build INSTALL.vcxproj in LLVM.sln using Visual Studio Community 2019: " 522>CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 (file): 522> file INSTALL cannot find? 522> "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include".? 522>Call Stack (most recent call first):? 522> tools/clang/lib/cmake_install.cmake:37 (include)? 522> tools/clang/cmake_install.cmake:54 (include)? 522> tools/cmake_install.cmake:43 (include)? 522> cmake_install.cmake:64 (include)? 522>? 522>? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: The command "setlocal? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmErrorLevel? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: exit /b %1? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :VCEnd" exited with code 1.? 522>Done building project "INSTALL.vcxproj" -- FAILED. " Everything else was built successfully, it's just this one project that it can't build. I checked in the file path it mentioned and I can see the "include" folder in there. So there's probably something I need to change in cmake_install.cmake. I've attached the file to this message. I hope someone will help me change it such that this will work. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.n092 at gmail.com Tue Apr 23 07:47:12 2019 From: ajay.n092 at gmail.com (Ajay Nanjundeshwar) Date: Tue, 23 Apr 2019 13:47:12 +0200 Subject: [CMake] Need help on to generate two CPACK/NSIS installers .exe for the same cmake project Message-ID: I am trying to generate two separate CPack/NSIS installers for the same cmake project on my windows machine. I have a working cmake project and also was able to generate one installer for it using cpack/nsis. But what i want to have is two separate installers generated at once (the idea is to have a second installer which will have some additional tools than the first one). is this possible through cpack? do i have to use something with the COMPONENT for this? Couldn't find any approaches for this kind of solution in any web forums, not able to figure out how this can be achieved. I am very new to cpack and also cmake. Any suggestions would really help! Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyacheslav.p.zakharin at intel.com Tue Apr 23 16:34:26 2019 From: vyacheslav.p.zakharin at intel.com (Zakharin, Vyacheslav P) Date: Tue, 23 Apr 2019 20:34:26 +0000 Subject: [CMake] Need help with CMake error "CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 file INSTALL cannot find "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include"." Message-ID: Can this still be considered something what CMake can handle the right way, please? cmake_install.cmake is supposed to be executed by CMake, so why would CMake use builder-specific representation of variables inside cmake_install.cmake? I understand that the user explicitly requested this by using CMAKE_CFG_INTDIR in the install() command, but isn?t it easy to handle CMAKE_CFG_INTDIR usage inside files generated for CMake processing like cmake_install.cmake? If $(Configuration) is replaced with ${BUILD_TYPE} it would work. I see that BUILD_TYPE is already passed to the cmake command for processing cmake_install.cmake, so I wonder if it is easy to do one step forward and resolve this issue in CMake. Thank you for considering this option. Thanks, Slava You're probably running into https://reviews.llvm.org/D58537#inline-532492. This is an LLVM issue, not a CMake issue. From: CMake > on behalf of Osman Zakir > Date: Monday, April 22, 2019 at 6:45 AM To: "cmake at cmake.org" > Subject: [CMake] Need help with CMake error "CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 file INSTALL cannot find "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include"." As the title says, I have this error when trying to build INSTALL.vcxproj in LLVM.sln using Visual Studio Community 2019: " 522>CMake Error at tools/clang/lib/Headers/cmake_install.cmake:36 (file): 522> file INSTALL cannot find? 522> "C:/llvm-project/build/$(Configuration)/lib/clang/9.0.0/include".? 522>Call Stack (most recent call first):? 522> tools/clang/lib/cmake_install.cmake:37 (include)? 522> tools/clang/cmake_install.cmake:54 (include)? 522> tools/cmake_install.cmake:43 (include)? 522> cmake_install.cmake:64 (include)? 522>? 522>? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: The command "setlocal? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmErrorLevel? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: exit /b %1? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :cmDone? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd? 522>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(138,5): error MSB3073: :VCEnd" exited with code 1.? 522>Done building project "INSTALL.vcxproj" -- FAILED. " Everything else was built successfully, it's just this one project that it can't build. I checked in the file path it mentioned and I can see the "include" folder in there. So there's probably something I need to change in cmake_install.cmake. I've attached the file to this message. I hope someone will help me change it such that this will work. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imbacen at gmail.com Wed Apr 24 17:37:51 2019 From: imbacen at gmail.com (cen) Date: Wed, 24 Apr 2019 23:37:51 +0200 Subject: [CMake] GTest confusion - linking to project being tested Message-ID: <903987bb-9492-0d5c-dc18-20f04eda3842@gmail.com> Hi I am essentially trying to solve this problem: https://stackoverflow.com/questions/19886397/how-to-solve-the-error-lnk2019-unresolved-external-symbol-function/30667584#30667584 and I have hit a wall. Using CMake to generate solution with two VC projects, one is a monolithic .exe the other is a gtest project meant to test a few functions from the exe. I am having a problem linking to main project in gtest project because: 1. The project being tested is an exe, not a lib. 2. Ideally I don't want to have all h/cpp files pulled up in the gtest project, only have the actual test files in there. 3. Adding the main project as a reference to gtest project didn't help (suggestion from SO thread). 4. Manually adding main project .obj files in gtest as linker input solves the problem and is essentially the solution I would like to achieve with CMake. 5. I hit another unpleasant snafu after #4 because main and gtest project implement a main() method and this fails to build. But I guess this can be avoided by renaming the gtest main and changing the entry point of the gtest project. So if 5 is solvable, what I really need is a CMake solution to #4.. to automatically build the tested project and link to it's object files in gtest project. This seems to me to be a really obvious case for testing so I am not sure whether it really is that complicated or I am doing things wrong. Bets regards, cen From francis.giraldeau at gmail.com Wed Apr 24 17:50:10 2019 From: francis.giraldeau at gmail.com (Francis Giraldeau) Date: Wed, 24 Apr 2019 17:50:10 -0400 Subject: [CMake] GTest confusion - linking to project being tested In-Reply-To: <903987bb-9492-0d5c-dc18-20f04eda3842@gmail.com> References: <903987bb-9492-0d5c-dc18-20f04eda3842@gmail.com> Message-ID: Split your monolithic executable into a library and its main: add_library(core core.cpp) add_executable(main main.cpp) target_link_libraries(main core) Then, you can create gtest file and link to the core lib: add_executable(test_core test_core.cpp) target_link_libraries(test_core gtest gtest_main core) add_test(NAME test_core COMMAND test_core) IMHO other tricks will make your build system hackish and error prone. You'd better keep the code and the tests in sync. The standard way is to just put the tests beside the code that it is testing. Francis Le mer. 24 avr. 2019 ? 17:38, cen a ?crit : > Hi > > I am essentially trying to solve this problem: > > https://stackoverflow.com/questions/19886397/how-to-solve-the-error-lnk2019-unresolved-external-symbol-function/30667584#30667584 > > and I have hit a wall. > > Using CMake to generate solution with two VC projects, one is a > monolithic .exe the other is a gtest project meant to test a few > functions from the exe. > > I am having a problem linking to main project in gtest project because: > > 1. The project being tested is an exe, not a lib. > > 2. Ideally I don't want to have all h/cpp files pulled up in the gtest > project, only have the actual test files in there. > > 3. Adding the main project as a reference to gtest project didn't help > (suggestion from SO thread). > > 4. Manually adding main project .obj files in gtest as linker input > solves the problem and is essentially the solution I would like to > achieve with CMake. > > 5. I hit another unpleasant snafu after #4 because main and gtest > project implement a main() method and this fails to build. But I guess > this can be avoided by renaming > > the gtest main and changing the entry point of the gtest project. > > > So if 5 is solvable, what I really need is a CMake solution to #4.. to > automatically build the tested project and link to it's object files in > gtest project. > > > This seems to me to be a really obvious case for testing so I am not > sure whether it really is that complicated or I am doing things wrong. > > > Bets regards, cen > > -- > > 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 laszlo.orban at balabit.com Thu Apr 25 03:29:19 2019 From: laszlo.orban at balabit.com (Orban, Laszlo) Date: Thu, 25 Apr 2019 09:29:19 +0200 Subject: [CMake] Fwd: CMAKE_HOST_SYSTEM_NAME is empty In-Reply-To: References: Message-ID: Hi all, Please help me an issue I'm facing with CMAKE_HOST_SYSTEM_NAME on FreeBSD 10.3. It gives back empty string, if I read it before the 'project(...)'. As far as I understood, CMAKE_SYSTEM_NAME can be used only after the 'project(...)' call, but CMAKE_HOST_SYSTEM_NAME should simply give back the result of 'uname -s' and could be used before 'project'. I'd like to use CMAKE_HOST_SYSTEM_NAME in my Compilers module to switch to clang instead of gcc in case if the host system is FreeBSD. CMakeLists.txt: ... include(Version) include(BuildType) include(Compilers) *message ( "!Before project='${CMAKE_HOST_SYSTEM_NAME}'" )* *project ( WanderfulProject LANGUAGES C )* *message ( "!After project='${CMAKE_HOST_SYSTEM_NAME}'" )* include(Endianness) include(GNUInstallDirs) include(Configure) ... Output: ... *!Before project=''* -- The C compiler identification is GNU 4.8.5 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done *!After project='FreeBSD'* *...* Additional info: $ cmake --version cmake version 3.4.1 $ uname -K 1003000 $ uname -s FreeBSD $ uname -m amd64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Apr 25 04:27:03 2019 From: d3ck0r at gmail.com (J Decker) Date: Thu, 25 Apr 2019 01:27:03 -0700 Subject: [CMake] ExternalProject_Add Visual Studio build Install Target Message-ID: I've had to make this modification the last few versions... cmake/share/cmake-3.14/Modules/ExternalProject.cmake line 1870 from if(step STREQUAL "INSTALL") list(APPEND args --target install) endif() to if(step STREQUAL "INSTALL") list(APPEND args --target INSTALL) endif() Otherwise, when building with visual studio, and trying to run the -install.rule rule, it says 'no such project' I don't think the same issue happens when building from the command line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forderud at gmail.com Thu Apr 25 06:04:24 2019 From: forderud at gmail.com (Fredrik Orderud) Date: Thu, 25 Apr 2019 12:04:24 +0200 Subject: [CMake] MSVC: How to disable manifest embedding? Message-ID: CMake seem to automatically add "/manifest:embed" to the linker options when building Windows EXE and DLL projects. This disables generation of a separate .manifest file for the binary, and instead embeds it into the EXE/DLL. I'm working on a project where I need the .manifest file, but I'm struggling to figure out how to achieve that. Any advise on how to get rid of the "/manifest:embed" linker option? My configuration: CMake 3.14.3, MSVC 20017. Thanks in advance, Fredrik Orderud From zehner.paul at jaxa.jp Fri Apr 26 01:35:10 2019 From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=) Date: Fri, 26 Apr 2019 05:35:10 +0000 Subject: [CMake] Support of compile features for Fujitsu C++ Compiler Message-ID: Hello Cmake community, I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler. I tested it on a simple project, and the line: ```cmake target_compile_features(test PUBLIC cxx_std_11) ``` fails with this message: ``` CMake Error at CMakeLists.txt:15 (target_compile_features): target_compile_features no known features for CXX compiler "Fujitsu" version . ``` So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features: ```cmake cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) project(foobar CXX) message("Your C++ compiler supports these C++ features:") foreach(i ${CMAKE_CXX_COMPILE_FEATURES}) message("${i}") endforeach() ``` and no feature are listed. So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu? Thanks for your help, -- Paul Zehner, Ph. D. Invited Researcher Numerical Simulation Research Unit Japan Aerospace Exploration Agency 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo 182-8522, Japan Tel. +81-50-3362-7933 Fax. +81-422-40-3327 zehner.paul at jaxa.jp www.jaxa.jp -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai.wolf at gmail.com Fri Apr 26 03:22:42 2019 From: kai.wolf at gmail.com (Kai Wolf) Date: Fri, 26 Apr 2019 09:22:42 +0200 Subject: [CMake] Support of compile features for Fujitsu C++ Compiler In-Reply-To: References: Message-ID: If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on. I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf Greetings, Kai http://kai-wolf.me http://effective-cmake.com > Am 26.04.2019 um 07:35 schrieb Zehner?Paul : > > Hello Cmake community, > > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html ), which talk about basic support of the compiler. > > I tested it on a simple project, and the line: > > ```cmake > target_compile_features(test PUBLIC cxx_std_11) > ``` > > fails with this message: > > ``` > CMake Error at CMakeLists.txt:15 (target_compile_features): > target_compile_features no known features for CXX compiler > > "Fujitsu" > > version . > > ``` > > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features: > > ```cmake > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) > project(foobar CXX) > message("Your C++ compiler supports these C++ features:") > foreach(i ${CMAKE_CXX_COMPILE_FEATURES}) > message("${i}") > endforeach() > ``` > > and no feature are listed. > > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu? > > Thanks for your help, > > -- > Paul Zehner, Ph. D. > Invited Researcher > Numerical Simulation Research Unit > Japan Aerospace Exploration Agency > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > 182-8522, Japan > Tel. +81-50-3362-7933 > Fax. +81-422-40-3327 > zehner.paul at jaxa.jp > www.jaxa.jp > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -------------- 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 zehner.paul at jaxa.jp Fri Apr 26 03:58:35 2019 From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=) Date: Fri, 26 Apr 2019 07:58:35 +0000 Subject: [CMake] Support of compile features for Fujitsu C++ Compiler In-Reply-To: References: , Message-ID: Kai, Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration. If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request. -- Paul Zehner, Ph. D. Invited Researcher Numerical Simulation Research Unit Japan Aerospace Exploration Agency 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo 182-8522, Japan Tel. +81-50-3362-7933 Fax. +81-422-40-3327 zehner.paul at jaxa.jp www.jaxa.jp ________________________________ From: Kai Wolf Sent: Friday, April 26, 2019 16:22 To: Zehner?Paul Cc: cmake at cmake.org Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on. I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf Greetings, Kai http://kai-wolf.me http://effective-cmake.com Am 26.04.2019 um 07:35 schrieb Zehner?Paul >: Hello Cmake community, I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler. I tested it on a simple project, and the line: ```cmake target_compile_features(test PUBLIC cxx_std_11) ``` fails with this message: ``` CMake Error at CMakeLists.txt:15 (target_compile_features): target_compile_features no known features for CXX compiler "Fujitsu" version . ``` So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features: ```cmake cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) project(foobar CXX) message("Your C++ compiler supports these C++ features:") foreach(i ${CMAKE_CXX_COMPILE_FEATURES}) message("${i}") endforeach() ``` and no feature are listed. So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu? Thanks for your help, -- Paul Zehner, Ph. D. Invited Researcher Numerical Simulation Research Unit Japan Aerospace Exploration Agency 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo 182-8522, Japan Tel. +81-50-3362-7933 Fax. +81-422-40-3327 zehner.paul at jaxa.jp www.jaxa.jp -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Apr 26 10:32:38 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 26 Apr 2019 10:32:38 -0400 Subject: [CMake] Support of compile features for Fujitsu C++ Compiler In-Reply-To: References: Message-ID: For an initial implementation I would base the work on the PGI compiler module ( https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake ) not the GNU-CXX module. This will allow you to add a new compiler with only meta-language flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of having to manually build the feature tables. On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul wrote: > > Kai, > > > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration. > > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request. > > > -- > > Paul Zehner, Ph. D. > > Invited Researcher > > Numerical Simulation Research Unit > > Japan Aerospace Exploration Agency > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > > 182-8522, Japan > > Tel. +81-50-3362-7933 > > Fax. +81-422-40-3327 > > zehner.paul at jaxa.jp > > www.jaxa.jp > > > > ________________________________ > From: Kai Wolf > Sent: Friday, April 26, 2019 16:22 > To: Zehner?Paul > Cc: cmake at cmake.org > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler > > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on. > > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf > > > Greetings, > > Kai > > http://kai-wolf.me > http://effective-cmake.com > > Am 26.04.2019 um 07:35 schrieb Zehner?Paul : > > Hello Cmake community, > > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler. > > I tested it on a simple project, and the line: > > ```cmake > target_compile_features(test PUBLIC cxx_std_11) > ``` > > fails with this message: > > ``` > CMake Error at CMakeLists.txt:15 (target_compile_features): > target_compile_features no known features for CXX compiler > > "Fujitsu" > > version . > > ``` > > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features: > > ```cmake > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) > project(foobar CXX) > message("Your C++ compiler supports these C++ features:") > foreach(i ${CMAKE_CXX_COMPILE_FEATURES}) > message("${i}") > endforeach() > ``` > > and no feature are listed. > > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu? > > Thanks for your help, > > -- > Paul Zehner, Ph. D. > Invited Researcher > Numerical Simulation Research Unit > Japan Aerospace Exploration Agency > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo > 182-8522, Japan > Tel. +81-50-3362-7933 > Fax. +81-422-40-3327 > zehner.paul at jaxa.jp > www.jaxa.jp > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From paul at mad-scientist.net Fri Apr 26 17:26:55 2019 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 26 Apr 2019 17:26:55 -0400 Subject: [CMake] How does IMPLICIT_DEPENDS work? Message-ID: We're trying to implement precompiled headers (yes, I've seen all the various github projects around this). As part of this we need to make sure the precompiled header is rebuilt whenever any of the headers that it includes changes: this seems like exactly the job for add_custom_command's IMPLICIT_DEPENDS. But, it doesn't seem to be doing anything at all for me so I wonder what I'm doing wrong. I'm using CMake 3.13.4 on GNU/Linux with GCC C++ and Makefile generators (we also will have support for MSVC but I'm not worried about that here). I have a function to deal with PCH generation: function(add_precompiled_header _target _header) ... # This is the actual command that does the precompiling add_custom_command( OUTPUT "${_pch_file}" COMMAND "${CMAKE_COMMAND}" -E make_directory "${_pch_dir}" COMMAND "${CMAKE_CXX_COMPILER}" "${_flags}" -x c++-header -o "${_pch_file}" "${_header}" COMMAND_EXPAND_LISTS IMPLICIT_DEPENDS CXX "${_header}" COMMENT "Precompiling ${_header} for ${_target} (C++)") ... get_property(_sources TARGET ${_target} PROPERTY SOURCES) foreach(_source ${_sources}) ... set_property(SOURCE ${_source} APPEND PROPERTY OBJECT_DEPENDS "${_pch_file}") ... endforeach() Obviously there're a lot of other things here I'm leaving out, but basically there's a custom command that compiles the header into a PCH and lists the header as an IMPLICIT_DEPENDS, and adds that PCH as an OBJECT_DEPENDS to the source files. When I change the PCH file, the source files are rebuilt so that works. If I change the header the PCH file is rebuilt so that works too. But if I change a header file that the PCH includes, the PCH is NOT rebuilt. Not only that but if I use "make -d" I can see that the PCH target never even considers any of the included files when determining out-of-date-ness of the PCH file. It seems like IMPLICIT_DEPENDS is behaving identically to DEPENDS here: only listing the header as a dependency but not trying to determine what it, itself, depends on. What am I doing wrong? Is there some subtlety to IMPLICIT_DEPENDS that I'm missing? From craig.scott at crascit.com Fri Apr 26 22:58:29 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 27 Apr 2019 12:58:29 +1000 Subject: [CMake] ctest // fixtures and --repeat-until-fail In-Reply-To: References: Message-ID: On Tue, Apr 16, 2019 at 11:36 PM Sergei Nikulov wrote: > > > > On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov < > sergey.nikulov at gmail.com> wrote: > >> > >> Hello All, > >> > >> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with > >> --repeat-until-fail option? > >> > >> My expectation, if I requesting a test run for example 10 times, the > >> sequence should be as follows: > >> > >> fixture_setup, then test, then fixture_cleanup repeats 10 times > >> > >> But in practice, I've got following sequence > >> > >> 1. fixture_setup runs 10 times > >> 2. test runs 10 times > >> 3. fixture_cleanup runs 10 times > >> > >> Is it expected behavior? > >> I'm using ctest version 3.14.2 > > > > > > The documentation for the --repeat-until-fail option says "Require each > test to run times without failing in order to pass". A fixture setup or > cleanup test is still a test, so they will also be run times. The logic > that implements repeating tests sets up a counter on each test and it runs > that test times before marking that test as complete. This is why you > see fixture_setup run 10 times, then test runs 10 times and lastly > fixture_cleanup runs 10 times. > > > > I understand that fixture is still a test. > To achieve repeatable behavior -R "test_continues_*" is enough. > > But if it calls FIXTURE why not apply the specific behavior as > expected from fixture (init/teardown)? > It's mostly related to the way it is implemented internally. Because a fixture setup/cleanup is still just another test, it has all the features of a regular test, including honouring the option that tells ctest to run it multiple times. For some projects, it may be desirable for the fixture setup/cleanup to run only once but re-run the fixture-requiring test(s) to run multiple times. For other projects, it might be desirable for the fixture setup/cleanup tests to also run multiple times (a setup test might simply be polling a service to confirm it is up, for example). Since ctest cannot know which of the two scenarios the project wants, it simply treats all tests the same, whether they are fixture setup/cleanup tests or not. Perhaps one way of dealing with this might be to add a new boolean test property which, when set, has the meaning of "only run once" when the --repeat-until-fail option is used. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Sat Apr 27 09:00:10 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Sat, 27 Apr 2019 13:00:10 +0000 Subject: [CMake] Can't Generate Project Files for VS2019 Message-ID: I'm having trouble using CMake to generate solution and project files for Emscripten and Binaryen. When I try to invoke it from the command line, I get this message: " cmake -G"Visual Studio 16 2019" -A Win64 -DCMAKE_INSTALL_PREFIX="C:/Program Files/binaryen" -DCMAKE_BUILD_TYPE=Release ../ CMake Error at CMakeLists.txt:1 (PROJECT):? Failed to run MSBuild command:? ? C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe? ? to get the value of VCTargetsPath:? ? Microsoft (R) Build Engine version 16.0.461+g6ff56ef63c for .NET Framework? Copyright (C) Microsoft Corporation. All rights reserved.? ? Build started 4/27/2019 5:48:57 PM.? Project "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" on node 1 (default targets).? C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='Win64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? Done Building Project "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default targets) -- FAILED.? ? Build FAILED.? ? "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default target) (1) ->? (_CheckForInvalidConfigurationAndPlatform target) ->? C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='Win64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? ? 0 Warning(s)? 1 Error(s)? ? Time Elapsed 00:00:00.20? ? ? Exit code: 1? ? ? ? -- Configuring incomplete, errors occurred!? See also "C:/binaryen/build/CMakeFiles/CMakeOutput.log". " Any help is appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Sat Apr 27 13:49:42 2019 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 27 Apr 2019 13:49:42 -0400 Subject: [CMake] How does IMPLICIT_DEPENDS work? In-Reply-To: References: Message-ID: <5fa7ec85c50605eec6514bd09642511e5c348fcb.camel@mad-scientist.net> On Fri, 2019-04-26 at 17:26 -0400, Paul Smith wrote: > We're trying to implement precompiled headers (yes, I've seen all the > various github projects around this). As part of this we need to make > sure the precompiled header is rebuilt whenever any of the headers that > it includes changes: this seems like exactly the job for > add_custom_command's IMPLICIT_DEPENDS. > > But, it doesn't seem to be doing anything at all for me so I wonder > what I'm doing wrong. OK, I figured out the issue. The problem is a combination of the way I was testing and a sort of bizarre "feature" of the CMake Makefile generator: The Makefile generator only generates prerequisite information when a CMake target is completely built. It doesn't generate the information when an individual object file is built. I was testing (to allow faster turnaround) by simply running: cmake ... make foo.cpp.o touch header.h make foo.cpp.o and the PCH file was not being rebuilt even though it included header.h. After MUCH tearing of hair and groping around in the generated makefiles, I realized that unless I built the full target and not just the individual object file, no prerequisite information was created. I had to run: cmake ... make footarget touch header.h make foo.cpp.o The first make would build foo.cpp.o and also generate all the prerequisite information as a side-effect of creating footarget. Then the second make would correctly update the PCH file in addition to rebuilding the object file. Note this is not related to PCH at all: you can reproduce this with the simplest of CMake configurations. That is definitely a subtlety of the makefile generator that was unexpected: maybe it will help someone else trying to do similar testing. From osmanzakir90 at hotmail.com Sun Apr 28 07:36:14 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Sun, 28 Apr 2019 11:36:14 +0000 Subject: [CMake] Can't Generate Project Files for VS2019 In-Reply-To: References: Message-ID: I just tried to build Step 1 of the CMake tutorial that comes with the source code (CMake version 3.14.3), once with VS2019 as the generator and then again with VS2017 as the generator. The latter worked fine but the former didn't. I got the same error as mentioned in the initial message: " cmake -G"Visual Studio 16 2019" -A Win64 -DCMAKE_INSTALL_PREFIX="C:/Program Files/binaryen" -DCMAKE_BUILD_TYPE=Release ../ CMake Error at CMakeLists.txt:1 (PROJECT):? Failed to run MSBuild command:? ? C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe? ? to get the value of VCTargetsPath:? ? Microsoft (R) Build Engine version 16.0.461+g6ff56ef63c for .NET Framework? Copyright (C) Microsoft Corporation. All rights reserved.? ? Build started 4/27/2019 5:48:57 PM.? Project "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" on node 1 (default targets).? C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='Win64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? Done Building Project "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default targets) -- FAILED.? ? Build FAILED.? ? "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default target) (1) ->? (_CheckForInvalidConfigurationAndPlatform target) ->? C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='Win64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? ? 0 Warning(s)? 1 Error(s)? ? Time Elapsed 00:00:00.20? ? ? Exit code: 1? ? ? ? -- Configuring incomplete, errors occurred!? See also "C:/binaryen/build/CMakeFiles/CMakeOutput.log". " When I try to look at the .vcxproj file mentioned in the error, I see that it can't find VS2019 Build Tools even though I do have them. I asked on MSDN forums but I don't have a reply there yet. And I don't know how to fix the issue myself, either. I would like for someone to please help me out with this. Is there a way for me to fix this problem? Like some sort of patch that can be added somewhere? I installed the binary for CMake 3.14.3 initially and only got the source code to try out the tutorial as a test for CMake; I'm not planning to try and build CMake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.svitok at gmail.com Sun Apr 28 15:25:27 2019 From: jan.svitok at gmail.com (Jano Svitok) Date: Sun, 28 Apr 2019 21:25:27 +0200 Subject: [CMake] Can't Generate Project Files for VS2019 In-Reply-To: References: Message-ID: Hi, Use 'x64' as platform. Jano On Sun, Apr 28, 2019, 13:36 Osman Zakir wrote: > I just tried to build Step 1 of the CMake tutorial that comes with the > source code (CMake version 3.14.3), once with VS2019 as the generator and > then again with VS2017 as the generator. The latter worked fine but the > former didn't. I got the same error as mentioned in the initial message: > > " > cmake -G"Visual Studio 16 2019" -A Win64 > -DCMAKE_INSTALL_PREFIX="C:/Program Files/binaryen" > -DCMAKE_BUILD_TYPE=Release ../ > CMake Error at CMakeLists.txt:1 (PROJECT):? > Failed to run MSBuild command:? > ? > C:/Program Files (x86)/Microsoft Visual > Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe? > ? > to get the value of VCTargetsPath:? > ? > Microsoft (R) Build Engine version 16.0.461+g6ff56ef63c for .NET > Framework? > Copyright (C) Microsoft Corporation. All rights reserved.? > ? > Build started 4/27/2019 5:48:57 PM.? > Project "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" on > node 1 (default targets).? > C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): > error : The OutputPath property is not set for project > 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified > a valid combination of Configuration and Platform for this project. > Configuration='Debug' Platform='Win64'. You may be seeing this message > because you are trying to build a project without a solution file, and have > specified a non-default Configuration or Platform that doesn't exist for > this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? > Done Building Project > "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default > targets) -- FAILED.? > ? > Build FAILED.? > ? > "C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj" (default > target) (1) ->? > (_CheckForInvalidConfigurationAndPlatform target) ->? > C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(775,5): > error : The OutputPath property is not set for project > 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified > a valid combination of Configuration and Platform for this project. > Configuration='Debug' Platform='Win64'. You may be seeing this message > because you are trying to build a project without a solution file, and have > specified a non-default Configuration or Platform that doesn't exist for > this project. [C:\binaryen\build\CMakeFiles\3.14.3\VCTargetsPath.vcxproj]? > ? > 0 Warning(s)? > 1 Error(s)? > ? > Time Elapsed 00:00:00.20? > ? > ? > Exit code: 1? > ? > ? > ? > -- Configuring incomplete, errors occurred!? > See also "C:/binaryen/build/CMakeFiles/CMakeOutput.log". > " > > When I try to look at the .vcxproj file mentioned in the error, I see that > it can't find VS2019 Build Tools even though I do have them. I asked on > MSDN forums but I don't have a reply there yet. And I don't know how to > fix the issue myself, either. > > I would like for someone to please help me out with this. Is there a way > for me to fix this problem? Like some sort of patch that can be added > somewhere? I installed the binary for CMake 3.14.3 initially and only got > the source code to try out the tutorial as a test for CMake; I'm not > planning to try and build 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 gjasny at googlemail.com Sun Apr 28 15:54:07 2019 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 28 Apr 2019 21:54:07 +0200 Subject: [CMake] Fwd: CMAKE_HOST_SYSTEM_NAME is empty In-Reply-To: References: Message-ID: Hello, On 25.04.19 09:29, Orban, Laszlo wrote: > Please help me an issue I'm facing with CMAKE_HOST_SYSTEM_NAME on > FreeBSD 10.3. It gives back empty string, if I read it before the > 'project(...)'. > As far as I understood, CMAKE_SYSTEM_NAME can be used only after the > 'project(...)' call, but CMAKE_HOST_SYSTEM_NAME should simply?give back > > Additional info: > > $ cmake --version > cmake version 3.4.1 In CMake 3.9.0 and later I made CMAKE_HOST_SYSTEM_NAME available in scritping context (which should also make it available prior to a project() call). Change: https://gitlab.kitware.com/cmake/cmake/merge_requests/499 Could you please re-try with latest CMake? Thanks, Gregor From paul at mad-scientist.net Sun Apr 28 21:25:00 2019 From: paul at mad-scientist.net (Paul Smith) Date: Sun, 28 Apr 2019 21:25:00 -0400 Subject: [CMake] How does IMPLICIT_DEPENDS work? In-Reply-To: <5fa7ec85c50605eec6514bd09642511e5c348fcb.camel@mad-scientist.net> References: <5fa7ec85c50605eec6514bd09642511e5c348fcb.camel@mad-scientist.net> Message-ID: <87397104ad4914097de7791fb81ea26a622986df.camel@mad-scientist.net> On Sat, 2019-04-27 at 13:49 -0400, Paul Smith wrote: > On Fri, 2019-04-26 at 17:26 -0400, Paul Smith wrote: > > We're trying to implement precompiled headers (yes, I've seen all the > > various github projects around this). As part of this we need to make > > sure the precompiled header is rebuilt whenever any of the headers that > > it includes changes: this seems like exactly the job for > > add_custom_command's IMPLICIT_DEPENDS. > > > > But, it doesn't seem to be doing anything at all for me so I wonder > > what I'm doing wrong. > > OK, I figured out the issue. The problem is a combination of the way I > was testing and a sort of bizarre "feature" of the CMake Makefile > generator I re-confirmed the documented restriction that IMPLICIT_DEPENDS is not available for non-Makefile generators (e.g., Ninja). Without this facility it seems impossible to support precompiled headers in CMake, so I've had to disable PCH for non-Makefile (and non- MSVC of course) generators. Is there any chance of getting IMPLICIT_DEPENDS support for Ninja? Is the reason that it's not supported because Ninja does its own dependency management or something like that? Does anyone know how it's done? Is it done by using the compiler flags like -MMD/-MP etc. or does it have its own built-in facility? From laszlo.orban at balabit.com Mon Apr 29 02:08:40 2019 From: laszlo.orban at balabit.com (Orban, Laszlo) Date: Mon, 29 Apr 2019 08:08:40 +0200 Subject: [CMake] Fwd: CMAKE_HOST_SYSTEM_NAME is empty In-Reply-To: References: Message-ID: Hi Gregor, I Installed cmake version 3.12.2 and I can confirm that it works, CMAKE_HOST_SYSTEM_NAME is available before the project() call Thank you very much for your assistance! Laszlo On Sun, Apr 28, 2019 at 9:54 PM Gregor Jasny wrote: > Hello, > > On 25.04.19 09:29, Orban, Laszlo wrote: > > Please help me an issue I'm facing with CMAKE_HOST_SYSTEM_NAME on > > FreeBSD 10.3. It gives back empty string, if I read it before the > > 'project(...)'. > > As far as I understood, CMAKE_SYSTEM_NAME can be used only after the > > 'project(...)' call, but CMAKE_HOST_SYSTEM_NAME should simply give back > > > > Additional info: > > > > $ cmake --version > > cmake version 3.4.1 > > In CMake 3.9.0 and later I made CMAKE_HOST_SYSTEM_NAME available in > scritping context (which should also make it available prior to a > project() call). > > Change: > https://gitlab.kitware.com/cmake/cmake/merge_requests/499 > > Could you please re-try with latest CMake? > > Thanks, > Gregor > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.svitok at gmail.com Mon Apr 29 15:45:03 2019 From: jan.svitok at gmail.com (Jano Svitok) Date: Mon, 29 Apr 2019 21:45:03 +0200 Subject: [CMake] Can't Generate Project Files for VS2019 In-Reply-To: References: Message-ID: On Sun, Apr 28, 2019 at 10:11 PM Osman Zakir wrote: > > For VS2017 I'd do "-G"Visual Studio 15 2017 Win64"". So for VS2019 it's "-G"Visual Studio 16 2019" -A x64"? Kind of weird in my opinion. Hi, sorry for brevity, I was replying from a phone. I hope you got it working in the mean time. Here is documentation for MS2017: https://cmake.org/cmake/help/v3.14/generator/Visual%20Studio%2015%202017.html#platform-selection Note that when you specify platform within generator name, you use Win64, but when using -A, you use x64. For VS2019, you have to use -A with x64, no other choices. Jano -------------- next part -------------- An HTML attachment was scrubbed... URL: