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 a
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:
http://www.cma
> 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:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h
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
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 "${CM
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
http://c
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
>
> D:\Code\hvtkm\vtkm\vtkm\
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 as
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15737
==
Reported By:Orion Poplawski
Assigned To:
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 [mailto:brad.k...@kitware.
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 of 8ea7611 that uses the
> -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 03
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
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
Blindly trusting Outlook D&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
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 pat
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 INFORMAT
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 libarchive
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 i
20 matches
Mail list logo