> -Original Message-
> From: Nils Gladitz [mailto:nilsglad...@gmail.com]
> Sent: Tuesday, August 02, 2016 10:47 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support
>
> On 07/20/2016 03:58 PM, Stuermer, Michael
On 08/02/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:
-Original Message-
From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Tuesday, August 02, 2016 10:47 AM
To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support
> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.
Huh, it doesn't look like that variable is set automatically when using
clang with the gcc toolchain. Is that supposed to happen?
It should be set manually (say, in a toolchain
On 07/30/2016 10:48 AM, David Keller wrote:
> This allows non-standard locations to be searched, e.g. brew, port.
Thanks, applied:
CMakeFindFrameworks: Allow custom framework locations
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9970cdcb
FYI, this module really only exists for legacy
On 07/29/2016 11:10 PM, Konstantin Sinitsyn wrote:
> After recent changes in FindProtobuf.cmake protobuf_generate_cpp
> doesn't take into account PROTOBUF_IMPORT_DIRS (in upper case) anymore.
[snip]
> Here's the patch to fix this:
Thanks, applied:
FindProtobuf: Restore support for
On 07/31/2016 03:56 PM, Sebastian Holtermann wrote:
>> I have updated the patch for CMake 3.6.0 to fix
>> https://gitlab.kitware.com/cmake/cmake/issues/16209
> Here is an updated patch.
Thanks. However, it is too late to restore this change for the 3.6
series. 3.6.1 reverted the change. We can
On 08/02/2016 01:08 PM, Brad King wrote:
> Ninja: Use full path for all source files
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0
I had to revert that because it causes the Qt*Autogen tests to
fail. Also it may break builds on Windows.
There are multiple problems:
*
On 07/22/2016 04:24 PM, Ryan D Retting wrote:
> I've been waiting for the following commit to get included in an official
> release. I just checked today's 3.6.1 and it's still not there.
3.6.1 is a patch release. Only documentation updates and fixes for regressions
from 3.5 are eligible for
On 07/20/2016 10:27 AM, Brad King wrote:
> On 07/06/2016 03:12 PM, Dāvis Mosāns wrote:
>> Otherwise it would use POSIX functions which works only for ASCII paths.
>
> Thanks. Applied to KWSys first with minor tweaks:
>
> http://review.source.kitware.com/21349
After being rewritten by another
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> Clang on Windows uses the GCC toolchain, so we need to avoid using
> backslashes for paths in response files.
[snip]
>strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
>
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> From: Chaoren Lin
>
> Relative paths are difficult for an IDE to parse the output of
> a build error.
Thanks, applied:
Ninja: Use full path for all source files
On 07/21/2016 08:43 PM, Dāvis Mosāns wrote:
> With MultiByteToWideChar such partial char would be replaced with ? (U+003F)
> or � (U+FFFD).
[snip]
> Also could check if last character is ? and try again with one byte less.
This may be a good middle ground. The excess bytes would then be buffered
On 08/02/2016 02:11 PM, Chaoren Lin wrote:
> Would changing ConvertToNinjaPath to output absolute paths paths work?
No, that will make all paths absolute. Ninja's design is pretty clear
in that it prefers canonical relative paths when possible.
Note that the conversion to a relative path by
On 07/29/2016 06:01 AM, Tobias Hunger wrote:
> I pushed an update that takes most of the feedback into account.
Thanks. I've applied the extra generator refactoring parts first:
Refactor extra generator registration to use factories
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc44627b
On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers wrote:
> Similarly, the :make command in vim will have no knowledge of build.gradle,
> and only tries to parse the build errors directly.
FWIW, I haven't encountered any problems with Vim's :make with CMake's
generated Ninja
> Ninja always uses the location of the build.ninja file as
> the current working directory, so an IDE that sees a relative
> path in an error message can interpret it relative to that.
Our IDE has no knowledge of the build.gradle file let alone where it is
located, it just sees the build output
29.07.2016, 23:56, "Konstantin Podsvirov" :
> Hello CMake developers,
>
> I found bug:
>
> https://gitlab.kitware.com/cmake/cmake/issues/16220
>
> I found it, but I do not want to deal with it ...
Okay, I have solution.
May be attached patch will be more useful then MR
2016-08-02 20:11 GMT+03:00 Brad King :
>
> How are we to know the encoding being produced by the child?
>
There isn't any reliable way to detect it, we just have to know what particular
application uses. Also there aren't any standard or API to determine it but
generally
The relative path is used whenever the build directory is under the source
directory (e.g., under src/build/), so it could still be out of source.
> FWIW, I haven't encountered any problems with Vim's :make with CMake's
> generated Ninja files in out-of-source builds for in-source or generated
>
On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:
Using the patchfile support I managed to implement the service installation
issue I had, so the unnecessary features from the last patch are removed now.
I tested all patches separately and hope they work now.
looking forward for
Tobias Hunger wrote:
> Hi Stephen,
>
> thanks for taking the time to do such a thorough review!
Actually my review wasn't thorough at all. I didn't try to review it
further.
The NewFactory methods in your patch don't return a new'd object, but
instead return static locals. The regular
21 matches
Mail list logo