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

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-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:

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:

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

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-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-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

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