[cmake-developers] install/local/fast and install/strip/fast are not fast

Hello everyone, Didn't trace back when this happened, but for quite a long time now install/local/fast and install/strip/fast targets, at least when using "Unix Makefiles" generator, are not at all fast. They depend on install/local and install/strip targets respectively instead of

[cmake-developers] Fixing up arbitrary Mac OS bundles

Hello, I'm trying to fixup an embedded bundle which is a QuickLook plugin. The bundle has .qtgenerator extension and should be located in .app/Contents/Library/QuickLook/.qtgenerator. This doesn't work right away. I've tried: 1. fixup_bundle(".app/Contents/Library/QuickLook/.qtgenerator" "" "")

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: > 2016-07-07 1:22 GMT+03:00 Mike Gelfand <mike...@mikedld.com>: >>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ >>> [snip] >>>private: >>> internal_buffer_type* buf_; >>> +#if !d

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

On 07/07/2016 12:42 AM, clin...@elemtech.com wrote: > From what I remember, WriteConsoleW doesn't support redirection to a > file or pipe. I don't see an alternative in the patch for the case > where stdout is not attached to the console. The SO thread I pointed at actually contained a check for

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/FStream.hxx.in > +++ b/Source/kwsys/FStream.hxx.in > @@ -14,33 +14,76 @@ > > #include <@KWSYS_NAMESPACE@/Encoding.hxx> > #include > +#if defined(_WIN32) && !defined(_MSC_VER) > +#include > +#endif > > namespace

Re: [cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and HasEnv functions

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/SystemInformation.cxx > +++ b/Source/kwsys/SystemInformation.cxx > @@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType; > # define USE_CPUID 0 > #endif > > +#include > + > #if USE_CPUID > > #define

Re: [cmake-developers] [PATCH v2] Improve encoding handling on Windows

For std::c(in|out|err) vs. std::wc(in|out|err), here's an implementation of std::streambuf which we currently use in our projects: http://stackoverflow.com/a/21728856/583456. You could either try using it as is or use it as a base for your own implementation; in any case, it's better than forcing

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

On 07/01/2016 05:12 PM, Ben Boeckel wrote: > On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: >> 2. change GetEnv to return std::unique_ptr which will be >> automatically deleted once out of scope and we still can check if there >> wasn't such env if it's empty. > Hrm. I'd rather

Re: [cmake-developers] How to set startup project in Visual Studio

Hello, On 06/18/2016 03:15 PM, Stephen Kelly wrote: > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the > property in the top-level directory, so thanks for that. > > However, the documentation

Re: [cmake-developers] Imported Locations in FindBoost.cmake

Hello, On 06/19/2016 02:00 PM, Andreas Weis wrote: > After fiddling around with the issue, I found that reversing the order > in which the IMPORTED_LOCATION_* fields on the imported target are being > set resolves the issue. It seems that the first configuration that's > added here will be used

Re: [cmake-developers] "Inconsistent sizeofcmds" on Mac

>>> Hello everyone, >>> >>> I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on >>> Mac with the following settings: >>> >>> CMAKE_OSX_ARCHITECTURES = i386;x86_64 >>> CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 >>> CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk >>> >>> Right after build,

[cmake-developers] "Inconsistent sizeofcmds" on Mac

Hello everyone, I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on Mac with the following settings: CMAKE_OSX_ARCHITECTURES = i386;x86_64 CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk Right after build, executable is runnable (from

Re: [cmake-developers] "Inconsistent sizeofcmds" on Mac

On Sep 17, 2015, at 11:44 PM, Clinton Stimpson wrote: > I'm not sure where the defect is, or how to work around it, without getting > more details. > > I've seen problems similar to this, but not exactly the same as what you are > seeing. What I have seen before was

Re: [cmake-developers] "Inconsistent sizeofcmds" on Mac

Hello, > On Sep 17, 2015, at 11:44 PM, Clinton Stimpson <clin...@elemtech.com> wrote: > > On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote: >> Hello everyone, >> >> I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on &

Re: [cmake-developers] A policy for Policies

On Sat, June 6, 2015 13:36, Stephen Kelly wrote: Code for Policies is also often complex. I often encounter Policies which are ancient and which get in the way of code clean up generally. Exactly the reason I don't understand why you'd want to add another policy to affect policies. Won't this