Re: [cmake-developers] [Patch 3/5] Improved WIX support

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

Re: [cmake-developers] [Patch 3/5] Improved WIX support

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

Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.

> 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

Re: [cmake-developers] [PATCH] Allow custom osx framework locations.

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

Re: [cmake-developers] FindProtobuf backward compatibility issue for PROTOBUF_IMPORT_DIRS

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

Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

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

Re: [cmake-developers] "Run ranlib on archives only if the tool is available" not in 3.6.1 release

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

Re: [cmake-developers] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too

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

Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

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

Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

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

Re: [cmake-developers] cmake -E capabilities [attempt 2]

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

> 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

Re: [cmake-developers] [ISSUE] Bump to 3.2 and continue...

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

Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

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

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

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 >

Re: [cmake-developers] [Patch 3/5] Improved WIX support

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

Re: [cmake-developers] cmake -E capabilities [attempt 2]

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