[Cmake-commits] CMake branch, master, updated. v3.14.0-550-g14b6cd4

t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 1500f07..3ca49f3 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 14) -set(CMake_VERSION_PATCH 20190327) +set(CMake_VER

Re: [CMake] Install without building unittests

Note, Im running from inside visual studio... I do realize for a makefile based system, I can run make install from inside the executable's build directory From: CMake On Behalf Of Scott Bloom Sent: Wednesday, March 27, 2019 7:23 PM To: cmake@cmake.org Subject: [CMake] Install without

[CMake] Install without building unittests

I asked this a couple of years ago, and the answer was "no"... If you run tests, it doesn't automatically build tests... So why does an install? I would never release something into the wild with out running the tests... But, for developer builds, were we need to install all the packages in

Re: [CMake] How can I automatically optionally build a submodule?

For me, this sounds more like foo is an independent thing and not a subdirectory. In this case, I think about two solutions:     1) Use a macro/function "check_yada", which sets a variable "yada_usable". If you extract this logic in an extra .cmake file, you can reuse it in your yada

Re: [CMake] How can I automatically optionally build a submodule?

"Simon Richter" wrote: > With my Debian Developer hat on: please also add a mechanism to manually > specify whether the optional component should be built. If the > dependency changes and suddenly a component goes missing without > triggering a build failure, that can be rather annoying for

Re: [CMake] How can I automatically optionally build a submodule?

"Albrecht Schlosser" wrote: > If you want yadda to be optional then don't use REQUIRED. > > find_package(yadda) > if (yadda_FOUND) >message(STATUS "found yadda, building bar ...") > ># add your code to build bar here > > endif () > > This should do what you want - unless I misunderstood

[Cmake-commits] CMake branch, master, updated. v3.14.0-549-g07dd1d2

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 07dd1d2782603126e65c57b3a71248dbdf83ed46 (commit) via

[Cmake-commits] CMake branch, release, updated. v3.14.0-20-g97c163f

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 97c163f5f7bd9c056b6ca0dd03f1b239ff61764b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-545-ga60f1c4

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via a60f1c4faf32e0e1d89a4f88e3b5851e1c0aec27 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-541-gc126e80

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via c126e80b5a7a9cf98ebea7c34a2b5b5f848dfab1 (commit) via

Re: [CMake] Parent component options passed to ExternalProject

Thanks for the help, I will give the FetchContent approach a shot and see how things go. I was actually in the process of trying to do a custom command using the built-in "cmake -E tar xvf" approach to roll a custom FetchContent that doesn't need such a new CMake, but I can't get it to work with

[Cmake-commits] CMake branch, master, updated. v3.14.0-537-gfcfbc01

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via fcfbc01d68aac2eca7435bfa0f01e5d1b3524303 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-514-gc518f30

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via c518f305bb8344e79cb2487f8bc0186a0b0c0336 (commit) via

[cmake-developers] Enhance CMake Comportment in AIX

Hello, I am working on the AIX port of the CMake. Something exists, but a large part is done using some flags, typically -expall and -G. These flag force AIX build chain to be more similar than Linux (e.g. use .so while AIX use .a). Unfortunately, this solution has side effect and means no any

Re: [CMake] Alternative to `add_compile_options` in Toolchain Files

Hi, If your CMake version is newer than 3.11 you can control what gets into the CMAKE__FLAGS_INIT flags with the technique from https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/ In your case you want to remove from the linker flags init the cxx compiler options. Cheers