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

2019-09-27 Thread Craig Scott
On Sat, Sep 28, 2019 at 1:31 PM melak47 wrote: > 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

Re: [CMake] Project Structure and add_subdirectory()

2019-09-27 Thread Avraham Shukron
On Sat, Sep 28, 2019 at 1:39 AM Marek Vojtko wrote: > 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,

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

2019-09-27 Thread melak47
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

2019-09-27 Thread Craig Scott
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 > > > Zde

Re: [CMake] Project Structure and add_subdirectory()

2019-09-27 Thread Marek Vojtko
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

2019-09-27 Thread Zdenko Podobny
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 g

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

2019-09-27 Thread fdk17
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 as

Re: [CMake] Project Structure and add_subdirectory()

2019-09-27 Thread Avraham Shukron
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 b

[CMake] printing CMAKE_CXX_FLAGS_* based on build type

2019-09-27 Thread Zdenko Podobny
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] Project Structure and add_subdirectory()

2019-09-27 Thread Marek Vojtko
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" se