[Cmake-commits] CMake branch, master, updated. v3.15.3-1230-g9cd47ff

t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index d9ca09b..775dc49 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,7 +1,7 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) -set(CMake_VERSION_PATCH 20190927) +set(CMake_VER

[CMake] Ninja generator emits order-only dependencies for custom commands

I'm using add_custom_command with the Ninja generator on Windows to invoke mc.exe on an .mc file, to generate an .rc file, to create a resource DLL. The full example is here: https://gist.github.com/melak47/f7d83046c6d57b338d633468d078f5b1 The problem is, changing the .mc file and rebuilding only

Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type

On Sat, Sep 28, 2019 at 8:15 AM Zdenko Podobny wrote: > Yes, build type is known (e.g value of ${CMAKE_BUILD_TYPE} is shown in > output). I use command like this: > cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=%INSTALL_DIR% > -DCMAKE_PREFIX_PATH=%INSTALL_DIR% -DCMAKE_BUILD_TYPE=Release > > >

Re: [CMake] Project Structure and add_subdirectory()

I agree that manually keeping track of transitive dependencies is a very bad and error-prone idea. The ideal solution is the separate repositories, but I don’t think that’s really feasible. The multi-root setup would work, but the ugly part of it is requiring an “app*_root” directory for each

Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type

Yes, build type is known (e.g value of ${CMAKE_BUILD_TYPE} is shown in output). I use command like this: cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=%INSTALL_DIR% -DCMAKE_PREFIX_PATH=%INSTALL_DIR% -DCMAKE_BUILD_TYPE=Release Zdenko pi 27. 9. 2019 o 23:54 fdk17 napísal(a): > Are you using a

Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type

Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a known value? Build type doesn’t have to be set and multi-config generators don’t use it. On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote: > Hello, > > I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE

Re: [CMake] Project Structure and add_subdirectory()

I think option 2 (keeping track on transitive dependencies) should be out of the question. It is bound to fail. Superbuild setup makes sense where all the components are part of a bigger whole. But if each application may depend on a different "flavor" of a dependency library, I think it should

[CMake] printing CMAKE_CXX_FLAGS_* based on build type

Hello, I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line statement but is does not work for me: message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}") Produce empy result, but message( STATUS "CXX compiler Release build

[Cmake-commits] CMake branch, master, updated. v3.15.3-1229-gc88cf48

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 c88cf48bbe775c45c36c23b990c89d85b7b9a220 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.15.3-1219-gd608b2c

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 d608b2c6200afd9d732c30c862bda923139a8d08 (commit) via

[CMake] Project Structure and add_subdirectory()

Using add_subdirectory() in a "superbuild" setup is straightforward: Create a root CMakeLists.txt which calls add_subdirectory() on all directories of your project and each target can then use target_link_libraries() without worrying where the target came from. Unfortunately the "superbuild"