Re: [cmake-developers] [PATCH] Add a test for checking that the CPack module produces correct config files

> My motivation is this. I want to submit a few improvements to the way CPack > writes config files, starting with that cpack_set_if_not_set change I > mentioned a while back. This functionality is generator-independent (and > basically unrelated to actual package generation), so I thought >

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

Thanks for the suggestions, Brad. Here is a set of three patches that breaks out the changes. For the HDF5_PREFER_PARALLEL implementation, I now use a list to set the names for find_program which does look much cleaner. I agree that having a NAMES_PER_DIR for find_program would be simpler from the

[Cmake-commits] CMake branch, next, updated. v3.3.1-2654-gcf3138b

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2656-g203306c

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2658-g71dd6bf

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2660-g5ce9fe1

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2662-gb104667

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2666-g70c864a

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2668-g1bc2c6d

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2670-gb53baca

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

Re: [CMake] Visual Studio - Ninja Generator

Hi, did you really enable parallel compiling in VS with /MP24 or the like? Note that using devenv to build uses the number from the IDE user settings but using msbuild needs a command line option. Else just create a custom target that calls cmake for ninja and afterwards ninja itself in yet

Re: [CMake] Visual Studio - Ninja Generator

El 31/08/15 a las 11:35, Guillaume Dumont escribió: Hi all, Using ninja is especially useful for projects with a lot of CUDA files which are built sequentially for every target using MSVS. I would like to contribute but I don't really know where to start and if such an effort already

Re: [CMake] Visual Studio - Ninja Generator

@Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there

Re: [CMake] Crawling documentation to find named argument keywords

On Monday, August 17, 2015 09:15:18 Michael Jackson wrote: > I thought there used to be a DocBook version of the documentation? At one > point I had an XML parser that used that as input to process the > documentation in the same way. the way the documentation is generated has changed with

Re: [CMake] linking: absolute path vs -l

On Friday, August 28, 2015 08:23:47 Nico Schlömer wrote: > Hi everyone, > > I'm curious about when CMake decides to link a library by its absolute path > and when it links using the `-l*` syntax. I came across this for the very > simple test problem > ``` > cmake_minimum_required(VERSION 3.0) >

[CMake] Happy Birthday CMake!

Today is the 15th birthday of CMake: http://www.kitware.com/blog/home/post/959 Thanks to everyone that has used and contributed to CMake over the years! -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

Hi, guys. It looks that an error ‘ld.bfd.exe: cannot find -l-Wl,-Bdynamic’ was introduced by commit 675ef165f213a6db1f9d0dfbebf6a0afc5469494 Author: Chuck Atkins Date: Fri Aug 7 15:11:57 2015 -0400 Allow LINK_SEARCH_{START,END}_STATIC props to have default values.

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

On 08/31/2015 11:16 AM, Mikhail Filimonov wrote: > It looks that an error ‘ld.bfd.exe: cannot find -l-Wl,-Bdynamic’ > > was introduced by > > commit 675ef165f213a6db1f9d0dfbebf6a0afc5469494 I discovered that problem in unrelated work last week and had prepared a commit to revert it. Chuck and

Re: [cmake-developers] FindZLIB module should find debug and, release variants

On 08/28/2015 05:37 PM, Michael Scott wrote: > Okay, I've modified the patch to only add the DEBUG and RELEASE > configurations when the corresponding library is found, and not set the > generic IMPORTED_LOCATION property at all. Thanks. We also need to be compatible with projects or scripts

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

On 08/31/2015 04:47 AM, Paul Romano wrote: > I'd like to offer the attached patch for consideration Thanks for working on these changes. Please split each independent fix out into its own commit with corresponding commit message explaining the change. For the HDF5_PREFER_PARALLEL

Re: [cmake-developers] CTest threshold exceeds 1024 bytes

On 08/31/2015 07:36 AM, "Roman Wüger" wrote: > Attached you will find the corrected patch. Thanks. I've attached a revised version. I renamed the options and added release notes. I also started the test case. Please try completing the test and getting it to pass from there. BTW, I noticed

Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)

On 08/31/2015 09:35 AM, Kislinskiy, Stefan wrote: > As there is already a patch for such a genex in bug 15509 and the > discussion in 5939 (both linked below in Brad's reply) started 7 > years ago... It would be a great pity to let this issue seep away > again. What can I do to help fixing this

Re: [cmake-developers] New policy to address rdynamic

So, from what I can tell, the Visual Studio generator and Xcode generator don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS. I know it's the generators and not platforms since my tests pass on these platforms with Makefile and Ninja generators but fail with Visual Studio and Xcode generators.

Re: [cmake-developers] New policy to address rdynamic

On 08/31/2015 03:44 PM, Chuck Atkins wrote: > the Visual Studio generator and Xcode generator > don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS This is likely true and has not been noticed because the Platform modules do not set any value for this variable on any platform supported by those

[cmake-developers] [CMake 0015722]: ExternalProject.cmake calls 'git stash save --all' even if git doesn't support --all option

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15722 == Reported By:Kevin Godby Assigned To:

Re: [cmake-developers] [Patch] Adding Windows 10 support

On 08/30/2015 06:41 PM, Gilles Khouzam wrote: > http://www.cmake.org/Bug/view.php?id=15670 > Add support for setting "Windows target platform version" in VS2015 Most of your changes look good but I think this issue needs more discussion. There is already some discussion in the issue tracker

[cmake-developers] Happy Birthday CMake!

Today is the 15th birthday of CMake: http://www.kitware.com/blog/home/post/959 Thanks to everyone that has used and contributed to CMake over the years! -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware

[cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries") introduced a few new ExportImport tests, and the check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. Make the regular expression matching the SONAME line output by readelf less strict, as the output format

Re: [cmake-developers] CTest threshold exceeds 1024 bytes

Hi Brad, sorry for the long response time, but I was on vacation. Attached you will find the corrected patch. Best regards Roman Am 20.08.15 um 17:30 schrieb Brad King > On 08/20/2015 06:30 AM, Roman Wüger wrote: > > > I made the "atoi" change but my problem is the test itself. > > > I

[cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

I'd like to offer the attached patch for consideration that fixes a number of issues with FindHDF5.cmake. The issues are as follows: 1. Searching for libraries related to the HL and Fortran_HL components is a bit broken at the moment; for example, if you specify the Fortran_HL component,

[Cmake-commits] CMake branch, master, updated. v3.3.1-1046-g02ab8e3

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2647-gcb09b3a

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

[cmake-developers] refactor-progress topic regressed Makefile progress

Steve, The topic merged here: Merge topic 'refactor-progress' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2985b9c0 sometimes breaks "make" progress. So far I've only been able to reproduce this when building CMake itself. In an up-to-date build tree I get output like: $ make ...

[cmake-developers] [CMake 0015721]: Indexer configuration of Eclipse CDT4 Project does not recognize symbols set by modules

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15721 == Reported By:Thomas Ruschival Assigned To:

[Cmake-commits] CMake branch, master, updated. v3.3.1-1032-g9a6d7d2

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1036-gd01e3c3

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1014-g97db5c5

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

[CMake] Visual Studio - Ninja Generator

Hi all, I would like to know what kind of effort would it take to generate a Visual Studio generator that bypasses the normal MSBuild build and uses Ninja instead. I have been working on different projects which build much faster with ninja than MSBuild (several orders of magnitude on a machine

[Cmake-commits] CMake branch, master, updated. v3.3.1-1028-g352e8e9

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1034-g5f6718c

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1043-g08ae6ce

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2645-g2af5650

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1045-g51d7a7b

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1040-ge18f6fe

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2650-gf83cd17

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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

As there is already a patch for such a genex in bug 15509 and the discussion in 5939 (both linked below in Brad's reply) started 7 years ago... It would be a great pity to let this issue seep away again. What can I do to help fixing this finally? Stefan -Original Message- From: