[Cmake-commits] CMake branch, master, updated. v3.11.1-650-g65a4b2a

VERSION_MINOR 11) -set(CMake_VERSION_PATCH 20180427) +set(CMake_VERSION_PATCH 20180428) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Multiple "projects" one directory

You can solve this by treating those local projects as external projects; then they can be built with independant flags include( ExternalProject ) https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L1769 ExternalProject_Add( ppc_portable SOURCE_DIR

[CMake] Multiple "projects" one directory

I have a rather complicated Qt based project. We are looking at rolling out a subset tool, and it will be significantly smaller in functionality. For that mode, I would like to set a CMake variable LITEVERSION that builds the tool with -DLITEVERSION defined. however, one (or two) folders, the

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

Craig Scott wrote: > This limitation has been intentional since target_link_libraries was first > created long before the others. It is the oldest of the target_ commands. > The original justification is that we don't want to allow this because it > makes it very easy for non-local commands to

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

On 04/27/2018 02:36 PM, Patrick Stotko wrote: > We can also continue the discussion at GitLab to avoid bothering the > others with such technical details if you like. Fine with me. I mainly wanted it brought up here to gain more attention. Interested followers can now jump to the issue:

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

Am 27.04.2018 um 15:13 schrieb Brad King: On 04/26/2018 07:18 PM, Craig Scott wrote: Perhaps it was an oversight that newer target_... commands don't have the same restriction as target_link_libraries(), but it is a very useful oversight! As the linked blog article explains, it allows much

Re: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

I recommend going with the custom target / custom command route. On Fri, Apr 27, 2018 at 5:19 AM, Stephen McDowell wrote: > Upon further inspection, it seems more related to PRE_BUILD. The step to > generating the files is through a add_custom_command call, which from the >

Re: [CMake] cmake --find-package deprecated?

Hi Alexander, all, here is a WIP patch https://gitlab.kitware.com/cmake/cmake/merge_requests/2017 Any advise, help on how to improve this is welcome. Alexis. On Tue, 2018-04-03 at 22:00 +0200, Alexander Neundorf wrote: > On 2018 M04 3, Tue 16:01:58 CEST jeandet wrote: > > Hi all, > > > >

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

On 04/26/2018 07:18 PM, Craig Scott wrote: > Perhaps it was an oversight that newer target_... commands don't have the same > restriction as target_link_libraries(), but it is a very useful oversight! > As the linked blog article explains, it allows much better modularity of the > project. Yes,

[Cmake-commits] CMake branch, master, updated. v3.11.1-649-g0036966

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

Re: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

Upon further inspection, it seems more related to PRE_BUILD. The step to generating the files is through a add_custom_command call, which from the docs apparently may end up being PRE_LINK. I tried generating into the ${CMAKE_CURRENT_SOURCE}/include/nanogui, which will work for Makefiles but

[CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

Hello, I have looked around and seen a few issues discussing this, but have not seen any solutions. It seems related to this: https://gitlab.kitware.com/cmake/cmake/issues/17450 In the sense that absolute paths are desired. 1. Previously,