Re: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015)

On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote: > I have been having problems with projects in VS14 and it appears > to be caused by the generation of paths used by/in the IDE > > D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h > > whereas it used to always be > >

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

On 09/11/2015 12:08 PM, Paul Romano wrote: > As requested, here's a new patch with the _NAMES variables unset()-ed > and documentation on the HDF5_PREFER_PARALLEL variable. Thanks. Applied and merged to 'next' for testing: FindHDF5: Add NAMES_PER_DIR and introduce HDF5_PREFER_PARALLEL

[cmake-developers] [CMake 0015737]: Use of redhat-hardened-ld breaks CMake's Fortran compiler library detection for gfortran

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15737 == Reported By:Orion Poplawski Assigned To:

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

Hello Brad, I added the required command line options, but it doesn't produce the expected output. It works in a normal environment, but not in the "CTest test case". Could you have a look at it? Best Regards Roman > -Ursprüngliche Nachricht- > Von: Brad King

Re: [cmake-developers] CMake user-provided manifest files (was: Windows: Correctly determine Windows version)

On 09/11/2015 11:45 AM, James Johnston wrote: > The second request is currently a big pain point with CMake to get working > correctly. Ideally I want to reproduce the VS way of doing things, which > is: > > a. Have link.exe generate default manifest for referencing the CRT > side-by-side

[CMake] Force rebuild of external project with Ninja

Dear all, I thought I would post this here before filing a bug, to see if anyone else has encountered this problem. The 'BUILD_ALWAYS 1' option for 'ExternalProject_Add' does not run the install command when used with Ninja. This behaviour can be demonstrated with the following project:

[Cmake-commits] CMake branch, next, updated. v3.3.1-2867-g1248582

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

[CMake] Ninja target aliases generation - mixing absolute target path with relative

Dear all, Project has following structure (and I can't change it) -project -module1 -CMakeLists.txt (module1 build rules, depends on module2 using add_subdirectory("../module2" "${binarypath}") -lib1 -CMakeLists.txt (depends on lib3) -lib2 -CMakeLists.txt

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

On 09/11/2015 12:37 PM, Roman Wüger wrote: > It works in a normal environment, but not in the "CTest test case". > Could you have a look at it? No, sorry. You're implementing this feature so it is up to you to debug and get it working. -Brad -- Powered by www.kitware.com Please keep messages

Re: [cmake-developers] Python extension to FindProtobuf

On 09/11/2015 11:11 AM, Andreas Bergmeier wrote: > Here is the commit. Thanks. Please revise the patch to also update the documentation of the module to mention the new API. > +list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py") > +add_custom_command( > + OUTPUT

Re: [CMake] FindMPI

Hi Nico, On Fri, Sep 11, 2015 at 4:53 PM, Nico Schlömer wrote: > I see from the CMake docs [1] that the recommended way for using MPI is to > call `find_package(MPI)` and set the linker and include flags appropriately. > On the other hand, I see from the OpenMPI specs

[CMake] FindMPI

Hi everyone, I see from the CMake docs [1] that the recommended way for using MPI is to call `find_package(MPI)` and set the linker and include flags appropriately. On the other hand, I see from the OpenMPI specs [2] that > The Open MPI team *strongly* recommends that you simply use Open MPI's

Re: [CMake] FindMPI

On 11/09/2015 10:53, Nico Schlömer wrote: Hi everyone, I see from the CMake docs [1] that the recommended way for using MPI is to call `find_package(MPI)` and set the linker and include flags appropriately. On the other hand, I see from the OpenMPI specs [2] that > The Open MPI team

Re: [cmake-developers] CMake user-provided manifest files

On 09/11/2015 02:09 PM, Brad King wrote: > I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > The source is full of comments about why it is there (incremental linking). > If someone can get an alternative approach working that also supports > user-provided .manifest files

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

> I have made the following changes in order to: > - support the UID/GID/UNAME/GNAME and permission on tar files at creation > time > - using directly libarchive in CPackDeb > - removing completely the need of fakeroot Applied to next for testing:

[CMake] Anyone got Clang/LLVM working natively on Windows

Hi Has anyone got Clang/LLVM working natively on Windows, and got CMake scripts for it ? Many thanks in advance, Aaron -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Le 11/09/15 21:34, Domen Vrankar a écrit : I have made the following changes in order to: - support the UID/GID/UNAME/GNAME and permission on tar files at creation time - using directly libarchive in CPackDeb - removing completely the need of fakeroot Applied to next for testing:

[Cmake-commits] CMake branch, next, updated. v3.3.1-2881-g57323ce

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

Re: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015)

Brad, I had a look at the .vcxproj files and there is no trace of odd paths in there. I realise now that I have #include statements of the kind #include And clearly it is VS that is appending these unixy paths to the (correct) cmake generated path prefix for the project etc. It appears to be

[CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY

I'm working with cmake version 2.8.12.2 on CentOS6. I've got a very simple project with one subdirectory. Each directory has a CMakeLists.txt file. The ADD_SUBDIRECTORY seems to remove the default generated CMAKE rule variables in the generation step. Is it normal? How to get an example without

Re: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY

PROJECT instruction MUST BE the first one after CMAKE_MINIMUM_REQUIRED: -- lib CMakeLists.txt { CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8) PROJECT(lib) ADD_SUBDIRECTORY(libtest) } From: CMake on behalf of Emmanuel HOUITTE Date: Friday 11 September 2015 15:26 To:

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

As requested, here's a new patch with the _NAMES variables unset()-ed and documentation on the HDF5_PREFER_PARALLEL variable. Best, Paul On Wed, Sep 9, 2015 at 7:00 PM, Brad King wrote: > On 09/03/2015 05:16 AM, Paul Romano wrote: > > Brad- here's a new patch based off

[Cmake-commits] CMake branch, next, updated. v3.3.1-2871-g18b3833

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1148-g2e11afd

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

[cmake-developers] Odd behaviour in VS14 (Visual studio 2015)

Using cmake 3.3.1 I have been having problems with projects in VS14 and it appears to be caused by the generation of paths used by/in the IDE D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h whereas it used to always be D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h Note the forwardslash

[cmake-developers] Python extension to FindProtobuf

Since beneath generating cpp and h files we often also want python bindings to be generated, I would like to have the following extension to FindProtobuf added. This adds protobuf_generate_python function. Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE

[Cmake-commits] CMake branch, master, updated. v3.3.1-1147-g8e88241

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1144-g8fb496a

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

[cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Hi Brad and Domen, This is a follow up of the following thread http://public.kitware.com/pipermail/cmake-developers/2015-August/026125.html I have made the following changes in order to: - support the UID/GID/UNAME/GNAME and permission on tar files at creation time - using directly

Re: [cmake-developers] Python extension to FindProtobuf

Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier: > Since beneath generating cpp and h files we often also want python bindings > to be generated, I would like to have the following extension to > FindProtobuf added. This adds protobuf_generate_python function. Forgot to add

Re: [cmake-developers] Python extension to FindProtobuf

Blindly trusting Outlook D was a bad idea ;) Here is the commit. (Sorry the footer is company policy) -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Freitag, 11. September 2015 17:07 To: cmake-developers@cmake.org

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch fixes the issue where on Windows 8 and above, by > default the system version returned is always Windows 8. > > In order for GetVersionEx to work properly, a manifest must be > embedded in the exe telling it to ignore the new behavior and

[Cmake-commits] CMake branch, next, updated. v3.3.1-2862-gdcb2768

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

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

Well this is quite cool. :) It's been an issue I've wanted to see addressed as well but haven't had the time to look at it. Not because of CMake itself not having a manifest (the improper GetVersionEx detection didn't affect me), but because I need to embed an app manifest in my own programs. I

Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator

> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Wednesday, September 09, 2015 15:00 > To: cmake-developers@cmake.org > Subject: Re: [cmake-developers] [CMake] Visual Studio - > Ninja Generator > > On 09/02/2015