Re: [cmake-developers] C# support ready for review

Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring

[Cmake-commits] CMake branch, master, updated. v3.5.0-rc2-91-gede2a6e

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

On Mittwoch, 17. Februar 2016 22:59:36 CET Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > > > >: > > > 1. Wouldn't it make sense you have a developer sprint

Re: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

hey, unfortunately i wont have the time to go dig in and provide a test for that .. my work on this project literally ends in one week. we've got our own fork of cmake (https://github.com/OpenCMISS-Dependencies/CMake) that contains fix. here's a patch (based on current master

Re: [cmake-developers] CMake Daemon blog

Taylor Braun-Jones wrote: > On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly > wrote: >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon >> >> The Kate plugin should soon appear here I think: >> >>

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" >: > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > I'd be in, but I do not have the time to organize one. I could

Re: [CMake] Incorporating cmake dir into configure.ac, but it depends on a autconf-managed in-tree library

On Thursday, February 11, 2016 13:11:29 Ron wrote: > Hi, > > I am working on a project that requires libevent and libevhtp. > The latter is cmake managed, my project and libevent are autoconf managed. > > (Note that libevhtp depends on libevent, both depend on openssl, which I > rely > on the

Re: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers

On Tuesday, February 16, 2016 10:49:24 Brad King wrote: > On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote: > > Just a small patch for the CodeBlocks generator > > Thanks! Applied: > > CodeBlocks: improve support for different compilers >

Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

I tested your fix, it's working well for my project. Thanks for the quick response! -Stephen S. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, February 17, 2016 3:28 PM To: Sorley, Stephen L. Cc: cmake-developers@cmake.org Subject: Re:

Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote: > FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating > solution files for Visual Studio on Windows (VS 2013 update 4, > to be specific). The ninja generator on Windows is unaffected. Thanks for trying the release candidate and tracking

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-190-ge0bc653

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

[cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution files for Visual Studio on Windows (VS 2013 update 4, to be specific). The ninja generator on Windows is unaffected. When I attempt to build a cuda target, the compile step for each .cu file fails with the following

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-188-g5f6fe80

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

Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

> On 17 Feb 2016, at 14:33, Brad King wrote: > > One could look at adding hooks to the compiler id logic to add alternatives > provided by the toolchain file. Or, we could provide a way to set the > compiler > id but not also skip other checks. In the worst case such a

Re: [CMake] compiler independent compiler flags

On 17-Feb-16 17:23, Nagy-Egri Máté Ferenc via CMake wrote: Unfortunately, I cannot help you in this regard, though I am surprised how little attention this question gained. I too feel that CMake could do better both in this regard. While ABI detection is very well done, BUILD_TYPE seems to

[cmake-developers] [CMake 0015978]: Visual Studio 2015 Update 2 CTP support

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15978 == Reported By:Niclas Larsén Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-186-gba18914

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-184-g06168be

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-180-g27dc919

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

Re: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

On 02/16/2016 03:46 PM, Daniel Wirtz wrote: > i think i've encountered a bug where the fourth (=SubDirectory) entry of > the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored. [snip] > The offending lines of code have been committed in 2006 with > c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i

[Cmake-commits] CMake branch, master, updated. v3.5.0-rc2-88-g0cd8633

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

[Cmake-commits] CMake branch, master, updated. v3.5.0-rc2-90-ged1b343

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

[Cmake-commits] CMake branch, master, updated. v3.5.0-rc2-86-g445a37f

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-178-g46678f7

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

Re: [cmake-developers] Pssible documentation error in install(TARGETS ) signature

On 02/16/2016 05:42 PM, Daniel Wirtz wrote: > if the order of the arguments matters: update documentation? Thanks, updated: Help: Clarify install(TARGETS) INCLUDES DESTINATION option https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c978223c -Brad -- Powered by www.kitware.com Please

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-173-g7ed1d19

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

Re: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

On 02/15/2016 12:47 PM, James Crosby wrote: > Using a dummy link command to check that linking works seems to > undermine the purpose of checking in the first place, which suggests > that perhaps it should still be possible to skip the check? For reference, this discussion has moved to the

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

On 02/16/2016 04:15 PM, Simon Richter wrote: > Hm, only problem is patch attribution here -- I've written that these > are from Wayne, and should be attributed to him (but submitting these > with his name in the From: field obviously would not have worked). IIRC if you commit with --author='...'

Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

Moving discussion to cmake-developers. On 02/15/2016 12:47 PM, James Crosby wrote: > I'm worried that built-in compiler detection might not be possible across > the variety of cross-compilers used. In some cases, for example, the > existence of a particular compiler, or a modified version of it,

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-171-gbef0a59

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-169-g02e0f70

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-167-gfd8d380

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

Re: [CMake] compiler independent compiler flags

> On 17.02.2016, at 11:23, Nagy-Egri Máté Ferenc via CMake > wrote: > > Sorry I could not help, but I do feel the struggle. LOL, yes. Struggle might be the right term. Best, Jan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

[CMake] compiler wrappers and linking libraries

Dear all, on a system with a cray compiler environment cmake fails to find a blas capable library via find_package(BLAS) The compilers on this system are wrappers which already link the local blas libraries (from the cray-libsci library). I guess this is why a call to

Re: [CMake] compiler independent compiler flags

Hi. There is certainly room for providing more, but BUILD_TYPE is not the only option settable in a compiler-agnostic way. There are target properties: C_STANDARD CXX_STANDARD INCLUDE_DIRECTORIES INTERPROCEDURAL_OPTIMIZATION POSITION_INDEPENDENT_CODE WIN32_EXECUTABLE and maybe more (I do not

Re: [CMake] compiler independent compiler flags

Hi Jan, Unfortunately, I cannot help you in this regard, though I am surprised how little attention this question gained. I too feel that CMake could do better both in this regard. While ABI detection is very well done, BUILD_TYPE seems to be the only compiler agnostic option available. I do

Re: [cmake-developers] Run program/command before test

Hi Nils, great thanks. Regards Roman > Am 17.02.2016 um 09:09 schrieb Nils Gladitz : > >> On 17.02.2016 07:58, Roman Wüger wrote: >> Ok thanks >> >> Would it be an opinion to have a COMMAND parameter for the add_test function >> like execute_process where every

Re: [cmake-developers] Run program/command before test

On 17.02.2016 07:58, Roman Wüger wrote: Ok thanks Would it be an opinion to have a COMMAND parameter for the add_test function like execute_process where every COMMAND must return the exit code and this would be ored? add_test(MyTest COMMAND myserver --port 80