[Cmake-commits] CMake branch, master, updated. v3.5.2-653-gb952336

_VERSION_MINOR 5) -set(CMake_VERSION_PATCH 20160513) +set(CMake_VERSION_PATCH 20160514) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Debug vs Release "install" area

I meant to also add; when I first was porting my projects to cmake, I thought this was a thing I wanted to do also... turns out, it's just a lot easier to make 2 build trees and build one release and one debug and have the same output image exactly for both... then install one or the other for use

Re: [CMake] Debug vs Release "install" area

On 2016-05-12 20:07- Scott Aron Bloom wrote: Looking for some advice. In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for

Re: [CMake] Debug vs Release "install" area

there is also BUILD_TYPE (not CMAKE_BUILD_TYPE, which is the initial condition) that often gets translated into. BUILD_TYPE seems to get set to the current building configuration. http://cmake.limitpoint.com/installing-multiple-build-types-in-cmake-generated-visual-studio-projects-2/

Re: [CMake] Debug vs Release "install" area

You could use conditional generator expressions e.g $ with a combination of add_custom_command stuff like "${CMAKE_COMMAND} -P yourscript.cmake " to handle the rest. Best Regards Roman > Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom : > > Looking for some advice. > > In

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On 05/13/2016 03:25 PM, Brad King wrote: > so for now please make your logic recognize this case and work around it. Please split this into two commits to move hunks like this: > + this->TargetAll = this->NinjaOutputPath("all"); > + this->CMakeCacheFile =

[CMake] ctest + timeout -> coredump, how?

Hi, I want to get coredump of test that was stopped by ctest because of timeout. I look at source code of cmake (kwsysProcessKill), and looks like there is no way to configure which signal number will be used to kill process. Am I right, and there is no way to force ctest to use signal that

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On 05/13/2016 12:13 PM, Nicolas Desprès wrote: > with a value that looks like this: > "-Wl,-bundle_loader,/Users/polrop/Documents/cmake/_build > ninja/Tests/ExportImport/Export/testExe2" > > lie on the caller site because the "if (li->IsPath)" in OutputLinkLibraries() > should not be true for

[cmake-developers] [PATCH] FindBoost: Boost 1.61

Boost 1.61 was released today. My boost-1.61 branch, merged into next, adds the updated dependency information for this release. The version information was already added, so is unchanged. Regards, Roger -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ

[Cmake-commits] CMake branch, next, updated. v3.5.2-1399-g238b58f

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, next has been updated via 238b58f12eaf04539a5e5d23aea474dfe3259b77 (commit) via

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

Am Freitag, 13. Mai 2016, 13:38:52 schrieb Brad King: > On 05/13/2016 12:21 PM, Rolf Eike Beer wrote: > >> Can you just use > >> > >> set_property(TARGET PkgConfig::${_prefix} PROPERTY ...) > >> > >> in each `if()` block? > > > > I had this before, but I thought I avoid multiple target

[Cmake-commits] CMake branch, next, updated. v3.5.2-1395-g744f771

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, next has been updated via 744f7717de3674bce41e59e9712db3fbff12b591 (commit) via

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

On 13/05/2016 14:36, Brad King wrote: On 05/12/2016 03:49 PM, Roger Leigh wrote: I have made the suggested changes above where this was possible, and merged the boost-component-headers branch into next for testing. Thanks. It looks pretty good, but there is one problem: +

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

On 05/13/2016 12:21 PM, Rolf Eike Beer wrote: >> Can you just use >> >> set_property(TARGET PkgConfig::${_prefix} PROPERTY ...) >> >> in each `if()` block? > > I had this before, but I thought I avoid multiple target lookups. You should > only ever see that message if none of the branches is

[Cmake-commits] CMake branch, next, updated. v3.5.2-1391-g3f70479

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, next has been updated via 3f70479e1714a16cd505d2930e414cb7cd72a5a2 (commit) via

Re: [CMake] [cmake-developers] CLang error when building iOS bundle

I don't know why I get this error, but after I link against missing required frameworks (OpenGLES, AssetsLibrary and QuartzCore) the error is gone. Regards Roman > Am 11.05.2016 um 22:48 schrieb Gregor Jasny via CMake : > > Hello, > >> On 11/05/16 21:22, Roman Wüger wrote: >>

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

Am Freitag, 13. Mai 2016, 11:16:28 schrieb Brad King: > On 05/13/2016 11:02 AM, Rolf Eike Beer wrote: > > Should all be done now. > > Thanks. > > The test fails for me with > > CMake Error at /.../Modules/FindPkgConfig.cmake:239 > (set_target_properties): set_target_properties called with

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On Thu, May 12, 2016 at 10:07 PM, Brad King wrote: > On 05/12/2016 02:16 PM, Nicolas Desprès wrote: > > All done. Thank you for taking a look. > > https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix > > The RunCMake.NinjaOutputPathPrefix test fails for

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

On 05/13/2016 11:02 AM, Rolf Eike Beer wrote: > Should all be done now. Thanks. The test fails for me with CMake Error at /.../Modules/FindPkgConfig.cmake:239 (set_target_properties): set_target_properties called with incorrect number of arguments. At least part of the problem is

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

Am Donnerstag, 12. Mai 2016, 13:17:42 schrieb Brad King: > On 05/12/2016 12:48 PM, Rolf Eike Beer wrote: > > Good point. I have changed this accordingly and pushed it to next. There > > are no tests yet, so maybe not immediately merge it to next but wait for > > the weekend or so. > > Okay,

[Cmake-commits] CMake branch, next, updated. v3.5.2-1389-gf4b4352

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, next has been updated via f4b43522ecd7880cd24b9f6895003342e476d06d (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1387-g260ea8d

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, next has been updated via 260ea8dd0faa80645eb78a421736e54a9796afdf (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1385-g9f530fc

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, next has been updated via 9f530fcc391a42fb80fa338fc35d82098b79dcb1 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.5.2-652-g131c00e

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1373-g71fa3a0

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, next has been updated via 71fa3a0c2418e3caed26aed3a31bde206c6d7132 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1370-gd33d03f

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, next has been updated via d33d03fc10466eac6bbbd11fc293604545977ebb (commit) via

[Cmake-commits] CMake branch, master, updated. v3.5.2-650-ga0e00c4

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1368-g35dad0b

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, next has been updated via 35dad0b0f5ed17effd9ed657a5838268145de3d4 (commit) via

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

On 05/12/2016 03:49 PM, Roger Leigh wrote: > I have made the suggested changes above where this was possible, and > merged the boost-component-headers branch into next for testing. Thanks. It looks pretty good, but there is one problem: > +find_path(Boost_${UPPERCOMPONENT}_HEADER > +

[cmake-developers] [CMake 0016103]: AUTORCC will not regenerate qrc when a resource changes

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16103 == Reported By:OregonGhost Assigned To:

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

On Fri, 13 May 2016 07:06:32 +1000 Craig Scott wrote: > Patrick, > > I suggest if you can reduce your problem down to a small, reproducible > example, then file a bug. I did a test just now with CMake 3.5.2 and > everything behaved as expected, including the header