From schueller at phimeca.com  Fri Jul  1 05:13:47 2016
From: schueller at phimeca.com (Julien Schueller)
Date: Fri, 1 Jul 2016 11:13:47 +0200 (CEST)
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <20160701021813.28657-1-davispuh@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
Message-ID: <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>


Hello, 

I'm using find_package in no-module mode with the PATHS option to provide a hard-coded guess to a path where a sublibrary 'hmat' was previously found, 
and with the NO_DEFAULT_PATH to not find it first in system directories. 
find_package (HMAT REQUIRED NO_MODULE PATHS <hmat-prefix>/lib/cmake/hmat NO_DEFAULT_PATH) 

So far so good. Now I want to cross-compile with the usual toolchain file: 
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32) 
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) 
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) 
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) 
... 
This works wonderfully too. 

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file to prevent detecting native libraries 
set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) 
And now find_package fails to find my package! 

I'm puzzled as I did not find in the doc something that explains why the PATHS is ignored (step #8 in find_package): 
https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package 

Do you think it's a bug ? 

Regards, 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/aef2b202/attachment.html>

From nilsgladitz at gmail.com  Fri Jul  1 06:37:47 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 1 Jul 2016 12:37:47 +0200
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
Message-ID: <577647FB.1030908@gmail.com>

On 07/01/2016 11:13 AM, Julien Schueller wrote:
>
> I'm using find_package in no-module mode with the PATHS option to 
> provide a hard-coded guess to a path where a sublibrary 'hmat' was 
> previously found,
> and with the NO_DEFAULT_PATH to not find it first in system directories.
> find_package (HMAT REQUIRED NO_MODULE PATHS 
> <hmat-prefix>/lib/cmake/hmat NO_DEFAULT_PATH)
>
> So far so good. Now I want to cross-compile with the usual toolchain file:
> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> ...
> This works wonderfully too.
>
> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my 
> toolchain file to prevent detecting native libraries
> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> And now find_package fails to find my package!
>
> I'm puzzled as I did not find in the doc something that explains why 
> the PATHS is ignored (step #8 in find_package):
> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package
>

The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed by the paths 
in CMAKE_FIND_ROOT_PATH.
Which means that (given ONLY) cmake only looks for the package in 
"/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".

You might want to e.g. add <hmat-prefix> to CMAKE_FIND_ROOT_PATH and use 
PATHS / instead.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/37ce7313/attachment.html>

From Tobias.Hunger at qt.io  Fri Jul  1 04:21:00 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Fri, 1 Jul 2016 08:21:00 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <CAFzjYVpjmi4zxy-TBVdBeQPZgx5vmdFVWmZHdTr5BbArRhn14w@mail.gmail.com>
References: <1467294716.811.298.camel@qt.io>
 <CAFzjYVpjmi4zxy-TBVdBeQPZgx5vmdFVWmZHdTr5BbArRhn14w@mail.gmail.com>
Message-ID: <1467361258.811.308.camel@qt.io>

On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote:
> It might be worthwhile to have the version section to have an explicit
> dirty key instead of having to parse the string key to find that
> information out.

I'll make that information available in a separate patch and add it.

> Also wouldn't you want server-mode to be an empty dictionary, as in
> the future that would contain information like the wire format
> version, etc.

Getting the information here would be expensive (I would need to instanciate a
cmServer to get the information) and I do not really see too big a need to add
that information in the first place. Long-term I will just require a cmake with
server-mode and "serverMode": "false" is enough to tell the user that she needs
to update her cmake:-)

The decision of which protocol to choose to talk to the server will be made
later, in a different part of the code.

Best Regards,
Tobias

-- 
Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From schueller at phimeca.com  Fri Jul  1 07:44:36 2016
From: schueller at phimeca.com (Julien Schueller)
Date: Fri, 1 Jul 2016 13:44:36 +0200 (CEST)
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <577647FB.1030908@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
 <577647FB.1030908@gmail.com>
Message-ID: <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>

> De: "Nils Gladitz" <nilsgladitz at gmail.com>
> ?: "Julien Schueller" <schueller at phimeca.com>, "cmake-developers"
> <cmake-developers at cmake.org>
> Envoy?: Vendredi 1 Juillet 2016 12:37:47
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 11:13 AM, Julien Schueller wrote:

>> I'm using find_package in no-module mode with the PATHS option to provide a
>> hard-coded guess to a path where a sublibrary 'hmat' was previously found,
>> and with the NO_DEFAULT_PATH to not find it first in system directories.
>> find_package (HMAT REQUIRED NO_MODULE PATHS <hmat-prefix>/lib/cmake/hmat
>> NO_DEFAULT_PATH)

>> So far so good. Now I want to cross-compile with the usual toolchain file:
>> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> ...
>> This works wonderfully too.

>> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file to
>> prevent detecting native libraries
>> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>> And now find_package fails to find my package!

>> I'm puzzled as I did not find in the doc something that explains why the PATHS
>> is ignored (step #8 in find_package):
>> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

> The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed by the paths in
> CMAKE_FIND_ROOT_PATH.
> Which means that (given ONLY) cmake only looks for the package in
> "/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".

> You might want to e.g. add <hmat-prefix> to CMAKE_FIND_ROOT_PATH and use PATHS /
> instead.

> Nils

Thanks, 

In my case <hmat-prefix> has the same value as CMAKE_FIND_ROOT_PATH, and even if I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the detection fails. 
(They're not actually set to /usr/i686-w64-mingw32 but some absolute location in my home where I unzip a mingw toolchain, but I can reproduce the issue on another box where the toolchain is natively /usr/i686-w64-mingw32). 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/cd8920fa/attachment-0001.html>

From nilsgladitz at gmail.com  Fri Jul  1 07:57:40 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 1 Jul 2016 13:57:40 +0200
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
 <577647FB.1030908@gmail.com>
 <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>
Message-ID: <57765AB4.5060003@gmail.com>



On 07/01/2016 01:44 PM, Julien Schueller wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Nils Gladitz" <nilsgladitz at gmail.com>
>     *?: *"Julien Schueller" <schueller at phimeca.com>,
>     "cmake-developers" <cmake-developers at cmake.org>
>     *Envoy?: *Vendredi 1 Juillet 2016 12:37:47
>     *Objet: *Re: [cmake-developers] PATHS guess in find_package
>     ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
>
>     On 07/01/2016 11:13 AM, Julien Schueller wrote:
>
>
>         I'm using find_package in no-module mode with the PATHS option
>         to provide a hard-coded guess to a path where a sublibrary
>         'hmat' was previously found,
>         and with the NO_DEFAULT_PATH to not find it first in system
>         directories.
>         find_package (HMAT REQUIRED NO_MODULE PATHS
>         <hmat-prefix>/lib/cmake/hmat NO_DEFAULT_PATH)
>
>         So far so good. Now I want to cross-compile with the usual
>         toolchain file:
>         set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>         set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>         set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>         set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>         ...
>         This works wonderfully too.
>
>         But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my
>         toolchain file to prevent detecting native libraries
>         set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>         And now find_package fails to find my package!
>
>         I'm puzzled as I did not find in the doc something that
>         explains why the PATHS is ignored (step #8 in find_package):
>         https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package
>
>
>     The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed by the
>     paths in CMAKE_FIND_ROOT_PATH.
>     Which means that (given ONLY) cmake only looks for the package in
>     "/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".
>
>     You might want to e.g. add <hmat-prefix> to CMAKE_FIND_ROOT_PATH
>     and use PATHS / instead.
>
>     Nils
>
>
> Thanks,
>
> In my case <hmat-prefix> has the same value as CMAKE_FIND_ROOT_PATH, 
> and even if I modify the PATHS option value to be relative (PATHS 
> lib/cmake/hmat) the detection fails.
> (They're not actually set to /usr/i686-w64-mingw32 but some absolute 
> location in my home where I unzip a mingw toolchain, but I can 
> reproduce the issue on another box where the toolchain is natively 
> /usr/i686-w64-mingw32).

I don't think behavior for relative paths is defined.

Use absolute paths like "/lib/cmake/hmat", just "/" probably works as 
well (since the path in the prefix matches 
"<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/").

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/89092510/attachment.html>

From ruslan_baratov at yahoo.com  Fri Jul  1 08:01:42 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Fri, 1 Jul 2016 15:01:42 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
	name from URL
Message-ID: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>

Hi,

With attached patch it's possible to extract name from URLs like 
'https://.../archive.tar.gz?a=x&b=y'.

Ruslo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-pattern-for-extracting-file-name-from-URL.patch
Type: text/x-patch
Size: 1441 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/c88b673b/attachment.bin>

From schueller at phimeca.com  Fri Jul  1 08:08:31 2016
From: schueller at phimeca.com (Julien Schueller)
Date: Fri, 1 Jul 2016 14:08:31 +0200 (CEST)
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <57765AB4.5060003@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
 <577647FB.1030908@gmail.com>
 <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>
 <57765AB4.5060003@gmail.com>
Message-ID: <99255226.769010.1467374911634.JavaMail.zimbra@phimeca.com>

> De: "Nils Gladitz" <nilsgladitz at gmail.com>
> ?: "Julien Schueller" <schueller at phimeca.com>, "cmake-developers"
> <cmake-developers at cmake.org>
> Envoy?: Vendredi 1 Juillet 2016 13:57:40
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 01:44 PM, Julien Schueller wrote:

>>> De: "Nils Gladitz" <nilsgladitz at gmail.com>
>>> ?: "Julien Schueller" <schueller at phimeca.com> , "cmake-developers"
>>> <cmake-developers at cmake.org>
>>> Envoy?: Vendredi 1 Juillet 2016 12:37:47
>>> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
>>> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

>>> On 07/01/2016 11:13 AM, Julien Schueller wrote:

>>>> I'm using find_package in no-module mode with the PATHS option to provide a
>>>> hard-coded guess to a path where a sublibrary 'hmat' was previously found,
>>>> and with the NO_DEFAULT_PATH to not find it first in system directories.
>>>> find_package (HMAT REQUIRED NO_MODULE PATHS <hmat-prefix>/lib/cmake/hmat
>>>> NO_DEFAULT_PATH)

>>>> So far so good. Now I want to cross-compile with the usual toolchain file:
>>>> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>>>> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>>> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>>> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>>> ...
>>>> This works wonderfully too.

>>>> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file to
>>>> prevent detecting native libraries
>>>> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>>> And now find_package fails to find my package!

>>>> I'm puzzled as I did not find in the doc something that explains why the PATHS
>>>> is ignored (step #8 in find_package):
>>>> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

>>> The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed by the paths in
>>> CMAKE_FIND_ROOT_PATH.
>>> Which means that (given ONLY) cmake only looks for the package in
>>> "/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".

>>> You might want to e.g. add <hmat-prefix> to CMAKE_FIND_ROOT_PATH and use PATHS /
>>> instead.

>>> Nils

>> Thanks,

>> In my case <hmat-prefix> has the same value as CMAKE_FIND_ROOT_PATH, and even if
>> I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the
>> detection fails.
>> (They're not actually set to /usr/i686-w64-mingw32 but some absolute location in
>> my home where I unzip a mingw toolchain, but I can reproduce the issue on
>> another box where the toolchain is natively /usr/i686-w64-mingw32).

> I don't think behavior for relative paths is defined.

> Use absolute paths like "/lib/cmake/hmat", just "/" probably works as well
> (since the path in the prefix matches
> "<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/").

> Nils

Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that that my absolute path begins with CMAKE_FIND_ROOT_PATH and hence should be treated as valid according to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ? 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/909e73c5/attachment-0001.html>

From robert.maynard at kitware.com  Fri Jul  1 08:15:43 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 1 Jul 2016 08:15:43 -0400
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1467361258.811.308.camel@qt.io>
References: <1467294716.811.298.camel@qt.io>
 <CAFzjYVpjmi4zxy-TBVdBeQPZgx5vmdFVWmZHdTr5BbArRhn14w@mail.gmail.com>
 <1467361258.811.308.camel@qt.io>
Message-ID: <CAFzjYVpg=_mLiXQfSXBEAdP3L71q6tPcPgyveyuYCMAOH95EOw@mail.gmail.com>

On Fri, Jul 1, 2016 at 4:21 AM, Tobias Hunger <Tobias.Hunger at qt.io> wrote:
> On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote:
>> It might be worthwhile to have the version section to have an explicit
>> dirty key instead of having to parse the string key to find that
>> information out.
>
> I'll make that information available in a separate patch and add it.

Thanks!

>
>> Also wouldn't you want server-mode to be an empty dictionary, as in
>> the future that would contain information like the wire format
>> version, etc.
>
> Getting the information here would be expensive (I would need to instanciate a
> cmServer to get the information) and I do not really see too big a need to add
> that information in the first place. Long-term I will just require a cmake with
> server-mode and "serverMode": "false" is enough to tell the user that she needs
> to update her cmake:-)
>
> The decision of which protocol to choose to talk to the server will be made
> later, in a different part of the code.
>

That is a very reasonable.


> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From nilsgladitz at gmail.com  Fri Jul  1 08:19:25 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 1 Jul 2016 14:19:25 +0200
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <99255226.769010.1467374911634.JavaMail.zimbra@phimeca.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
 <577647FB.1030908@gmail.com>
 <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>
 <57765AB4.5060003@gmail.com>
 <99255226.769010.1467374911634.JavaMail.zimbra@phimeca.com>
Message-ID: <57765FCD.9060105@gmail.com>



On 07/01/2016 02:08 PM, Julien Schueller wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Nils Gladitz" <nilsgladitz at gmail.com>
>     *?: *"Julien Schueller" <schueller at phimeca.com>,
>     "cmake-developers" <cmake-developers at cmake.org>
>     *Envoy?: *Vendredi 1 Juillet 2016 13:57:40
>     *Objet: *Re: [cmake-developers] PATHS guess in find_package
>     ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
>
>
>
>     On 07/01/2016 01:44 PM, Julien Schueller wrote:
>
>
>
>         ------------------------------------------------------------------------
>
>             *De: *"Nils Gladitz" <nilsgladitz at gmail.com>
>             *?: *"Julien Schueller" <schueller at phimeca.com>,
>             "cmake-developers" <cmake-developers at cmake.org>
>             *Envoy?: *Vendredi 1 Juillet 2016 12:37:47
>             *Objet: *Re: [cmake-developers] PATHS guess in
>             find_package ignored with NO_DEFAULT_PATH &
>             CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
>
>             On 07/01/2016 11:13 AM, Julien Schueller wrote:
>
>
>                 I'm using find_package in no-module mode with the
>                 PATHS option to provide a hard-coded guess to a path
>                 where a sublibrary 'hmat' was previously found,
>                 and with the NO_DEFAULT_PATH to not find it first in
>                 system directories.
>                 find_package (HMAT REQUIRED NO_MODULE PATHS
>                 <hmat-prefix>/lib/cmake/hmat NO_DEFAULT_PATH)
>
>                 So far so good. Now I want to cross-compile with the
>                 usual toolchain file:
>                 set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>                 set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>                 set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>                 set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>                 ...
>                 This works wonderfully too.
>
>                 But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to
>                 ONLY in my toolchain file to prevent detecting native
>                 libraries
>                 set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>                 And now find_package fails to find my package!
>
>                 I'm puzzled as I did not find in the doc something
>                 that explains why the PATHS is ignored (step #8 in
>                 find_package):
>                 https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package
>
>
>             The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed
>             by the paths in CMAKE_FIND_ROOT_PATH.
>             Which means that (given ONLY) cmake only looks for the
>             package in
>             "/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".
>
>             You might want to e.g. add <hmat-prefix> to
>             CMAKE_FIND_ROOT_PATH and use PATHS / instead.
>
>             Nils
>
>
>         Thanks,
>
>         In my case <hmat-prefix> has the same value as
>         CMAKE_FIND_ROOT_PATH, and even if I modify the PATHS option
>         value to be relative (PATHS lib/cmake/hmat) the detection fails.
>         (They're not actually set to /usr/i686-w64-mingw32 but some
>         absolute location in my home where I unzip a mingw toolchain,
>         but I can reproduce the issue on another box where the
>         toolchain is natively /usr/i686-w64-mingw32).
>
>
>     I don't think behavior for relative paths is defined.
>
>     Use absolute paths like "/lib/cmake/hmat", just "/" probably works
>     as well (since the path in the prefix matches
>     "<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/").
>
>     Nils
>
>
> Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that 
> that my absolute path begins with CMAKE_FIND_ROOT_PATH and hence 
> should be treated as valid according 
> to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ?

CMake could do a lot of things but as-is the defined (documented) 
behavior is that when you tell cmake to only look in the prefixes 
provided by CMAKE_FIND_ROOT_PATH then all search locations are re-rooted 
to those prefixes.

e.g. a given path "/usr" can exist under your regular filesystem root 
and as /usr/i686-w64-mingw32/usr.
Still you would not want cmake to look in your native /usr directory in 
this case even though it is "valid" (exists).

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/d61be778/attachment.html>

From daniel at pfeifer-mail.de  Fri Jul  1 08:25:02 2016
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Fri, 1 Jul 2016 14:25:02 +0200
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <20160701021813.28657-1-davispuh@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
Message-ID: <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>

Hi D?vis,

On Fri, Jul 1, 2016 at 4:18 AM, D?vis Mos?ns <davispuh at gmail.com> wrote:
> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.

Your change to the SystemTools::GetEnv function introduces memory
leaks, since you return a pointer to a new[]-ed array.
It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
and provide interface compatability.
You should probably introduce a function that returns std::string and
uses GetEnvironmentVariableW internally.

> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
>
> Next, when we're outputing to console need to use wide functions.
>
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

Sounds useful. I cannot really comment on this.

Cheers, Daniel

From schueller at phimeca.com  Fri Jul  1 08:28:28 2016
From: schueller at phimeca.com (Julien Schueller)
Date: Fri, 1 Jul 2016 14:28:28 +0200 (CEST)
Subject: [cmake-developers] PATHS guess in find_package ignored with
 NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
In-Reply-To: <57765FCD.9060105@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <16353177.488934.1467364427090.JavaMail.zimbra@phimeca.com>
 <577647FB.1030908@gmail.com>
 <1577503543.735558.1467373476859.JavaMail.zimbra@phimeca.com>
 <57765AB4.5060003@gmail.com>
 <99255226.769010.1467374911634.JavaMail.zimbra@phimeca.com>
 <57765FCD.9060105@gmail.com>
Message-ID: <624625222.803970.1467376108319.JavaMail.zimbra@phimeca.com>

> De: "Nils Gladitz" <nilsgladitz at gmail.com>
> ?: "Julien Schueller" <schueller at phimeca.com>, "cmake-developers"
> <cmake-developers at cmake.org>
> Envoy?: Vendredi 1 Juillet 2016 14:19:25
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 02:08 PM, Julien Schueller wrote:

>>> De: "Nils Gladitz" <nilsgladitz at gmail.com>
>>> ?: "Julien Schueller" <schueller at phimeca.com> , "cmake-developers"
>>> <cmake-developers at cmake.org>
>>> Envoy?: Vendredi 1 Juillet 2016 13:57:40
>>> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
>>> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

>>> On 07/01/2016 01:44 PM, Julien Schueller wrote:

>>>>> De: "Nils Gladitz" <nilsgladitz at gmail.com>
>>>>> ?: "Julien Schueller" <schueller at phimeca.com> , "cmake-developers"
>>>>> <cmake-developers at cmake.org>
>>>>> Envoy?: Vendredi 1 Juillet 2016 12:37:47
>>>>> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
>>>>> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

>>>>> On 07/01/2016 11:13 AM, Julien Schueller wrote:

>>>>>> I'm using find_package in no-module mode with the PATHS option to provide a
>>>>>> hard-coded guess to a path where a sublibrary 'hmat' was previously found,
>>>>>> and with the NO_DEFAULT_PATH to not find it first in system directories.
>>>>>> find_package (HMAT REQUIRED NO_MODULE PATHS <hmat-prefix>/lib/cmake/hmat
>>>>>> NO_DEFAULT_PATH)

>>>>>> So far so good. Now I want to cross-compile with the usual toolchain file:
>>>>>> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>>>>>> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>>>>> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>>>>> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>>>>> ...
>>>>>> This works wonderfully too.

>>>>>> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file to
>>>>>> prevent detecting native libraries
>>>>>> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>>>>> And now find_package fails to find my package!

>>>>>> I'm puzzled as I did not find in the doc something that explains why the PATHS
>>>>>> is ignored (step #8 in find_package):
>>>>>> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

>>>>> The given path "<hmat-prefix>/lib/cmake/hmat" is prefixed by the paths in
>>>>> CMAKE_FIND_ROOT_PATH.
>>>>> Which means that (given ONLY) cmake only looks for the package in
>>>>> "/usr/i686-w64-mingw32/<hmat-prefix>/lib/cmake/hmat".

>>>>> You might want to e.g. add <hmat-prefix> to CMAKE_FIND_ROOT_PATH and use PATHS /
>>>>> instead.

>>>>> Nils

>>>> Thanks,

>>>> In my case <hmat-prefix> has the same value as CMAKE_FIND_ROOT_PATH, and even if
>>>> I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the
>>>> detection fails.
>>>> (They're not actually set to /usr/i686-w64-mingw32 but some absolute location in
>>>> my home where I unzip a mingw toolchain, but I can reproduce the issue on
>>>> another box where the toolchain is natively /usr/i686-w64-mingw32).

>>> I don't think behavior for relative paths is defined.

>>> Use absolute paths like "/lib/cmake/hmat", just "/" probably works as well
>>> (since the path in the prefix matches
>>> "<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/").

>>> Nils

>> Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that that my
>> absolute path begins with CMAKE_FIND_ROOT_PATH and hence should be treated as
>> valid according to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ?

> CMake could do a lot of things but as-is the defined (documented) behavior is
> that when you tell cmake to only look in the prefixes provided by
> CMAKE_FIND_ROOT_PATH then all search locations are re-rooted to those prefixes.

> e.g. a given path "/usr" can exist under your regular filesystem root and as
> /usr/i686-w64-mingw32/usr.
> Still you would not want cmake to look in your native /usr directory in this
> case even though it is "valid" (exists).

> Nils

I see your point. 
Thank you so much for the quick response. 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/1df88342/attachment-0001.html>

From brad.king at kitware.com  Fri Jul  1 08:58:01 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 08:58:01 -0400
Subject: [cmake-developers] [patch] Document -H and -B
In-Reply-To: <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
References: <c391e994-cd36-a61c-05ee-7b86fbc28a99@yahoo.com>
 <5775738F.8000709@kitware.com>
 <a9dcf1b6-5434-cc83-8eec-f51736a6ff3f@yahoo.com>
 <57757E7B.9050904@kitware.com>
 <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com>
 <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com>
 <CALSpCT0n3jUUSuYD7SneoBT0suP5YB2CYUNsyP1=aLsLb013ZQ@mail.gmail.com>
 <a8a2d867-0fc1-1f22-b527-3982961ec370@yahoo.com>
 <CALSpCT115zzJgKz4=dS_yPkzf=xvCp10BTOfaj4osUReLbcoEQ@mail.gmail.com>
 <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com>
 <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
Message-ID: <577668D9.5070104@kitware.com>

On 06/30/2016 05:35 PM, Dave Gittins wrote:
> I don't understand the harm of documenting the options and making
> them public.

The discussion got side-tracked on how to do it with the currently
documented interface.

> Seems to me that they are
> a) used
> b) useful
> c) safe

We can consider making them public but in addition to the documentation
we should:

* Consider providing alternative options with more intuitive names
  and making those public instead.  Currently "-H" stands for "Home"
  which is an internal name within CMake's implementation and is not
  a name whose meaning is public-facing.

* Allow the form `-H <value> -B <value>` with the new names.

* Extend the test suite (e.g. RunCMake.CommandLine) with cases
  covering the public-facing options.

-Brad

From brad.king at kitware.com  Fri Jul  1 08:58:16 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 08:58:16 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
Message-ID: <577668E8.8070306@kitware.com>

On 07/01/2016 08:01 AM, Ruslan Baratov via cmake-developers wrote:
> With attached patch it's possible to extract name from URLs like 
> 'https://.../archive.tar.gz?a=x&b=y'.

Thanks.

>          elseif(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
> -          message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
> +          # Try: https://.../archive.tar.gz?a=x&b=y
> +          string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
> +          set(fname "${CMAKE_MATCH_1}")
> +          if(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
> +            message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
> +          endif()

Please try to structure the logic right in the if/elseif part.
Matching in those also sets `CMAKE_MATCH_*` variables so one
does not need to double-match.

Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.

Thanks,
-Brad


From brad.king at kitware.com  Fri Jul  1 08:59:11 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 08:59:11 -0400
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1467364292.811.344.camel@qt.io>
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io>
Message-ID: <5776691F.5020907@kitware.com>

On 07/01/2016 05:11 AM, Tobias Hunger wrote:
>> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> I do not see why this information is need to set up a cmake project. I need two
> directories and a generator. Do I need to know what the generator produces at
> that point?

If we don't foresee a use case for it we don't need to add it now.  The
example given in the issue was just a quick demo IIUC and not intended to
be authoritative result of deep design thought.

> * "Visual Studio 10 2010",
> * "Visual Studio 10 2010 Win64" and
> * "Visual Studio 10 2010 IA64"
[snip]
> The cmake command line lets me apparently use "-A platform"
[snip]
> Why can I specify the platform names in two different ways? Why do
> the two ways disagree on the platform name ("Win64" vs. "x64")?

See here:

 https://cmake.org/cmake/help/v3.6/generator/Visual%20Studio%2014%202015.html

At one time the generator name was the only way.  The names were not
originally chosen to match VS's platform names and were then kept for
compatibility.  The -A/CMAKE_GENERATOR_PLATFORM approach was added
more recently to decouple the generator name from the target architecture.

> What is the preferred way to set up a Visual studio project nowadays?

The preferred way is now:

  -G "Visual Studio 10 2010" -A x64

Its usage is not widespread because it doesn't make that much difference
for x64 and the feature has only been around for a couple years.

> If "-A" is the way to go, then I would like to try my hand at adding
> a method to retrieve all valid platforms for a generator. CMake has
> a lot of code to find those names (or hardcodes known names), so why
> not pass it on to the user?

If it is reasonably straightforward to do then go for it.  That would
be nice to offer.

> So far I only looked into the visual studio generators, so I might
> have missed something that blocks such a method in other generators.

The Xcode generator supports CMAKE_GENERATOR_TOOLSET but not
CMAKE_GENERATOR_PLATFORM.  The Makefile and Ninja generators support
neither because they are expected to be run from an environment that
is already configured for a given toolchain/architecture.

-Brad


From ben.boeckel at kitware.com  Fri Jul  1 09:04:59 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 1 Jul 2016 09:04:59 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <577668E8.8070306@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
Message-ID: <20160701130459.GA25200@megas.kitware.com>

On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:
> Also, the `([^/]*)\\?.*` part of the regex should be more
> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.

This should also probably skip '#' characters for URLs with anchors.

--Ben

From brad.king at kitware.com  Fri Jul  1 09:09:55 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 09:09:55 -0400
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
Message-ID: <57766BA3.1040600@kitware.com>

On 07/01/2016 08:25 AM, Daniel Pfeifer wrote:
> On Fri, Jul 1, 2016 at 4:18 AM, D?vis Mos?ns <davispuh at gmail.com> wrote:
>> On Windows getenv uses ANSI codepage so it needs to be encoded to
>> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
>> and encode that.

Thanks.  Clinton (in Cc) did quite a bit of work to get argv[] and
file processing to use wide character APIs on Windows.  It looks like
environment variables are next.

> Your change to the SystemTools::GetEnv function introduces memory
> leaks, since you return a pointer to a new[]-ed array.
> It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
> and provide interface compatability.

We could keep our own std::map around to own the memory and use that
to retain compatibility in the existing API.

It would be nice to also offer an alternative API that passes
ownership of the result to the caller.

> You should probably introduce a function that returns std::string and
> uses GetEnvironmentVariableW internally.

The signature also needs to allow callers to determine whether the
environment variable was set to empty or not set at all.

Thanks,
-Brad


From davispuh at gmail.com  Fri Jul  1 09:44:32 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Fri, 1 Jul 2016 16:44:32 +0300
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
Message-ID: <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>

2016-07-01 15:25 GMT+03:00 Daniel Pfeifer <daniel at pfeifer-mail.de>:

> Hi D?vis,
>
> On Fri, Jul 1, 2016 at 4:18 AM, D?vis Mos?ns <davispuh at gmail.com> wrote:
> > On Windows getenv uses ANSI codepage so it needs to be encoded to
> > internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> > and encode that.
>
> Your change to the SystemTools::GetEnv function introduces memory
> leaks, since you return a pointer to a new[]-ed array.
> It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
> and provide interface compatability.
> You should probably introduce a function that returns std::string and
> uses GetEnvironmentVariableW internally.
>
>
I know about memory leak, I intentionally left it this way for first version
of patch as there are multiple ways how to implement it properly.

POSIX's getenv doesn't need to be freed, but here for Windows since we need
to encode it to internal encoding we'll be returning a new pointer.

I see two ways:

1. add SystemTools::FreeEnv which delete's if on Windows but does nothing
  otherwise;
2. change GetEnv to return std::unique_ptr<std:string> which will be
  automatically deleted once out of scope and we still can check if there
  wasn't such env if it's empty.

To me 2nd option seems best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/f0be1d32/attachment.html>

From ben.boeckel at kitware.com  Fri Jul  1 10:12:47 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 1 Jul 2016 10:12:47 -0400
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
 <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
Message-ID: <20160701141247.GA23108@megas.kitware.com>

On Fri, Jul 01, 2016 at 16:44:32 +0300, D?vis Mos?ns wrote:
> 2. change GetEnv to return std::unique_ptr<std:string> 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 use std::optional than relying on implicit nullptr
semantics.

--Ben

From daniel at pfeifer-mail.de  Fri Jul  1 10:16:19 2016
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Fri, 1 Jul 2016 16:16:19 +0200
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <20160701141247.GA23108@megas.kitware.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
 <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
 <20160701141247.GA23108@megas.kitware.com>
Message-ID: <CANZMcXqSbchoR7FBd0qtL=PPPD1F5NL3tQHkyvagXSRQvoo5EQ@mail.gmail.com>

On Fri, Jul 1, 2016 at 4:12 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Fri, Jul 01, 2016 at 16:44:32 +0300, D?vis Mos?ns wrote:
>> 2. change GetEnv to return std::unique_ptr<std:string> 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 use std::optional than relying on implicit nullptr
> semantics.

+1.

This class here should be renamed to cmOptional and moved to its own
file, so it may be reused:
http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22

From brad.king at kitware.com  Fri Jul  1 10:38:38 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 10:38:38 -0400
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <CANZMcXqSbchoR7FBd0qtL=PPPD1F5NL3tQHkyvagXSRQvoo5EQ@mail.gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
 <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
 <20160701141247.GA23108@megas.kitware.com>
 <CANZMcXqSbchoR7FBd0qtL=PPPD1F5NL3tQHkyvagXSRQvoo5EQ@mail.gmail.com>
Message-ID: <5776806E.5020205@kitware.com>

On 07/01/2016 10:16 AM, Daniel Pfeifer wrote:
>> Hrm. I'd rather use std::optional than relying on implicit nullptr
>> semantics.
> 
> +1.
> 
> This class here should be renamed to cmOptional and moved to its own
> file, so it may be reused:
> http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22

The GetEnv method in question is in KWSys which has clients besides
CMake.  I'd like to avoid adding an Optional class to it or using
C++11 in it.  Please see my response in another part of this thread.

-Brad


From mikedld at mikedld.com  Fri Jul  1 10:41:38 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Fri, 1 Jul 2016 17:41:38 +0300
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <20160701141247.GA23108@megas.kitware.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
 <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
 <20160701141247.GA23108@megas.kitware.com>
Message-ID: <8587cb6a-b973-2fa3-d9a2-c4aed4a3c75c@mikedld.com>

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<std:string> 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 use std::optional than relying on implicit nullptr
> semantics.

Since you already have "bool SystemTools::GetEnv(const char* key,
std::string& result)", another option would be to use it everywhere and
maybe introduce something like "bool SystemTools::HasEnv(const char*
key)" for those several cases where you only need to check the existence.

Regards,
Mike

From ruslan_baratov at yahoo.com  Fri Jul  1 11:48:41 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Fri, 1 Jul 2016 18:48:41 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20160701130459.GA25200@megas.kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com> <20160701130459.GA25200@megas.kitware.com>
Message-ID: <75eb66e6-5b04-b68c-1e50-cf7271ac853d@yahoo.com>

On 01-Jul-16 16:04, Ben Boeckel wrote:
> On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:
>> Also, the `([^/]*)\\?.*` part of the regex should be more
>> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> This should also probably skip '#' characters for URLs with anchors.
>
> --Ben
'fragement' goes after 'query' so as far as I understand it's not necessary.
https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

Ruslo

From ruslan_baratov at yahoo.com  Fri Jul  1 11:48:58 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Fri, 1 Jul 2016 18:48:58 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <577668E8.8070306@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
Message-ID: <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>

On 01-Jul-16 15:58, Brad King wrote:
> On 07/01/2016 08:01 AM, Ruslan Baratov via cmake-developers wrote:
>> With attached patch it's possible to extract name from URLs like
>> 'https://.../archive.tar.gz?a=x&b=y'.
> Thanks.
>
>>           elseif(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
>> -          message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
>> +          # Try: https://.../archive.tar.gz?a=x&b=y
>> +          string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
>> +          set(fname "${CMAKE_MATCH_1}")
>> +          if(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
>> +            message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
>> +          endif()
> Please try to structure the logic right in the if/elseif part.
> Matching in those also sets `CMAKE_MATCH_*` variables so one
> does not need to double-match.
'elseif' part try to find 'archive.tar.gz' in '${fname}', then 
'string(REGEX' try to match it in '${url}'. There is no reusing of 
'CMAKE_MATCH_*'.

>
> Also, the `([^/]*)\\?.*` part of the regex should be more
> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
We can't have question mark ('?') in path as far as I understand, it 
should be percent-encoded, will be |'%3F'.|||
https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax
https://en.wikipedia.org/wiki/Percent-encoding

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160701/582a39dc/attachment.html>

From Tobias.Hunger at qt.io  Fri Jul  1 05:11:34 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Fri, 1 Jul 2016 09:11:34 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <57756C41.5070001@kitware.com>
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
Message-ID: <1467364292.811.344.camel@qt.io>

On Do, 2016-06-30 at 15:00 -0400, Brad King wrote:
> On 06/30/2016 09:51 AM, Tobias Hunger wrote:
> > Compared to the bug report mentioned above the fields "multiconfig" and
> > "recursive" are missing. I could not figure out how to get that
> > information:-/
> 
> There is no "recursive" generator, so that does not belong in the example
> anyway.??The Makefile generator does not produce recursive makefiles:
> 
> ?https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.
> 3F

Great, one thing less to worry about:-)

> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> Something similar will have to be added to the generator factory APIs
> so that we can ask for this information without creating a generator.

Sorry for not knowing any better... But does it make sense to provide that
information?

I do not see why this information is need to set up a cmake project. I need two
directories and a generator. Do I need to know what the generator produces at
that point?

Once I get the project structure I have the information on the generated
configurations -- incl. their names.

Either we should have multiConfig return a list of configuration names that will
be generated or I do not see any need to have the information in the first
place.

> > I could also not yet figure out a way to retrieve information on supported
> > platforms and toolsets. At least I did get whether a generator supports
> > toolsets, but nothing similar seems to exist for the platform part.
> 
> We don't have any information on supported platforms or toolsets.
> The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings
> take user-specified values and we pass them through to native tools.
> It is up to the user to provide valid values.

Looking at the code I am a bit confused:

All the generators that take a platform seem to get that set via the generator
name. E.g. there are
* "Visual Studio 10 2010",
* "Visual Studio 10 2010 Win64" and
* "Visual Studio 10 2010 IA64"
generators registered.

All these different names trigger a new generator to be created with different
DefaultPlatformName set up (even though the documentation string for the
generators reports the Win64/IA64 part as "[arch]", not platform).

Note that "Win64" gets mapped to a platform name of "x64" and "IA64" gets mapped
to "Itanium".

So far so good...


The cmake command line lets me apparently use "-A platform" to set
cmake::GeneratorPlatform. That will end up in the cache as
"CMAKE_GENERATOR_PLATFORM" (after some validation).

Generators will get that value from the cmMakefiles (where they move into via
the CMakeCache AFAICT). That information will be passed to the generator via the
SetGeneratorPlatform method, which will then override the default platform set
via the generator name.


Why can I specify the platform names in two different ways? Why do the two ways
disagree on the platform name ("Win64" vs. "x64")? Did you rename the concept
from architecture to platform at some point (or why does the documentation use
[arch] and the command line client "-A")? I guess there are interesting
compatibility considerations behind all this:-)

What is the preferred way to set up a Visual studio project nowadays? Should I
filter out the architecture specific generators in favor or using -A on the
command line or the other way around? Or do both cover completely separate use
cases?

If "-A" is the way to go, then I would like to try my hand at adding a method to
retrieve all valid platforms for a generator. CMake has a lot of code to find
those names (or hardcodes known names), so why not pass it on to the user?

So far I only looked into the visual studio generators, so I might have missed
something that blocks such a method in other generators.

Best Regards,
Tobias

-- 
Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From ben.boeckel at kitware.com  Fri Jul  1 13:52:11 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 1 Jul 2016 13:52:11 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <75eb66e6-5b04-b68c-1e50-cf7271ac853d@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <20160701130459.GA25200@megas.kitware.com>
 <75eb66e6-5b04-b68c-1e50-cf7271ac853d@yahoo.com>
Message-ID: <20160701175211.GA11864@megas.kitware.com>

On Fri, Jul 01, 2016 at 18:48:41 +0300, Ruslan Baratov wrote:
> On 01-Jul-16 16:04, Ben Boeckel wrote:
> > On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:
> >> Also, the `([^/]*)\\?.*` part of the regex should be more
> >> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> > This should also probably skip '#' characters for URLs with anchors.
> >
> > --Ben
> 'fragement' goes after 'query' so as far as I understand it's not necessary.
> https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

Right, but if there isn't a query part:

    foo.tar.gz#some_anchor

--Ben

From brad.king at kitware.com  Fri Jul  1 15:35:43 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 1 Jul 2016 15:35:43 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
Message-ID: <5776C60F.8070901@kitware.com>

On 07/01/2016 11:48 AM, Ruslan Baratov wrote:
> On 01-Jul-16 15:58, Brad King wrote:
>> Please try to structure the logic right in the if/elseif part.
>> Matching in those also sets `CMAKE_MATCH_*` variables so one
>> does not need to double-match.
> 'elseif' part try to find 'archive.tar.gz' in '${fname}', then 'string(REGEX' try to match it in '${url}'. There is no reusing of 'CMAKE_MATCH_*'.

I don't think we should duplicate the

  "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"

expression.  The stripping of ?.* can be done earlier, or done as
part of the main match.

>> Also, the `([^/]*)\\?.*` part of the regex should be more
>> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> We can't have question mark ('?') in path as far as I understand, it should be percent-encoded, will be |'%3F'.|||
> https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax
> https://en.wikipedia.org/wiki/Percent-encoding

In that case it won't hurt to exclude `?` and `#` from the
allowed matching.

Thanks,
-Brad


From dave.gittins at gmail.com  Fri Jul  1 17:31:43 2016
From: dave.gittins at gmail.com (Dave Gittins)
Date: Sat, 2 Jul 2016 07:31:43 +1000
Subject: [cmake-developers] [patch] Document -H and -B
In-Reply-To: <577668D9.5070104@kitware.com>
References: <c391e994-cd36-a61c-05ee-7b86fbc28a99@yahoo.com>
 <5775738F.8000709@kitware.com>
 <a9dcf1b6-5434-cc83-8eec-f51736a6ff3f@yahoo.com>
 <57757E7B.9050904@kitware.com>
 <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com>
 <577583AA.90006@kitware.com>
 <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com>
 <CALSpCT0n3jUUSuYD7SneoBT0suP5YB2CYUNsyP1=aLsLb013ZQ@mail.gmail.com>
 <a8a2d867-0fc1-1f22-b527-3982961ec370@yahoo.com>
 <CALSpCT115zzJgKz4=dS_yPkzf=xvCp10BTOfaj4osUReLbcoEQ@mail.gmail.com>
 <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com>
 <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
 <577668D9.5070104@kitware.com>
Message-ID: <CAB4NfKSMy+hmgVjQaYxnrCRx=WPTkksxWA5OH94E4fJ1Ax6Q_A@mail.gmail.com>

That sounds good.
On 1 Jul 2016 22:58, "Brad King" <brad.king at kitware.com> wrote:

> On 06/30/2016 05:35 PM, Dave Gittins wrote:
> > I don't understand the harm of documenting the options and making
> > them public.
>
> The discussion got side-tracked on how to do it with the currently
> documented interface.
>
> > Seems to me that they are
> > a) used
> > b) useful
> > c) safe
>
> We can consider making them public but in addition to the documentation
> we should:
>
> * Consider providing alternative options with more intuitive names
>   and making those public instead.  Currently "-H" stands for "Home"
>   which is an internal name within CMake's implementation and is not
>   a name whose meaning is public-facing.
>
> * Allow the form `-H <value> -B <value>` with the new names.
>
> * Extend the test suite (e.g. RunCMake.CommandLine) with cases
>   covering the public-facing options.
>
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160702/fc445f68/attachment.html>

From clinton at elemtech.com  Fri Jul  1 18:24:23 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Fri, 1 Jul 2016 16:24:23 -0600 (MDT)
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <8587cb6a-b973-2fa3-d9a2-c4aed4a3c75c@mikedld.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <CANZMcXob33mY467JNjkaLOUE7nKQPCP-VhC3M7VqrzaP-CqFpA@mail.gmail.com>
 <CAOE4rSxGmj=J7nt8cxMDJbPgCC++Ruu-fXyeGvu-+FnCG+h9+g@mail.gmail.com>
 <20160701141247.GA23108@megas.kitware.com>
 <8587cb6a-b973-2fa3-d9a2-c4aed4a3c75c@mikedld.com>
Message-ID: <1765159422.125674298.1467411863929.JavaMail.zimbra@elemtech.com>



----- On Jul 1, 2016, at 8:41 AM, Mike Gelfand mikedld at mikedld.com wrote:

> 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<std:string> 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 use std::optional than relying on implicit nullptr
>> semantics.
> 
> Since you already have "bool SystemTools::GetEnv(const char* key,
> std::string& result)", another option would be to use it everywhere and
> maybe introduce something like "bool SystemTools::HasEnv(const char*
> key)" for those several cases where you only need to check the existence.
> 

+1

- Clint

From clinton at elemtech.com  Fri Jul  1 18:54:26 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Fri, 1 Jul 2016 16:54:26 -0600 (MDT)
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <20160701021813.28657-1-davispuh@gmail.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
Message-ID: <2045206281.125728767.1467413666925.JavaMail.zimbra@elemtech.com>



----- On Jun 30, 2016, at 8:18 PM, D?vis Mos?ns davispuh at gmail.com wrote:

> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.
> 
> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
> 
> Next, when we're outputing to console need to use wide functions.
> 
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

...

> +#if defined(_WIN32)
> +  // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> +  // (and all other std::w*) fails once it encounters non-ASCII
> +  // string unless locale is set.
> +  // Note that even with this, seems it can't output characters
> +  // which aren't present in ANSI codepage no matter what encoding
> +  // is used for console.
> +  // Also once any character outside of ANSI codepage is tried to
> +  // be outputed then after there anymore won't be output from
> +  // any of std::w* functions.
> +  _wsetlocale(LC_ALL, L"");
> +#endif

The _wsetlocale() may be a problem.

See:
https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
https://cmake.org/Bug/view.php?id=16099


> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
>       typedef std::basic_filebuf<CharType,Traits> my_base_type;
>       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
>       {
> +        std::wstring wstr = Encoding::ToWide(s);
> +        const wchar_t *ws = wstr.c_str();
> +#if defined(_MSC_VER) && _MSC_VER >= 1400
> +        const wchar_t *ss = ws;
> +#else
> +        const char *ss = 0;
> +        size_t length = std::wcstombs(0, ws, 0);
> +        if (length != size_t(-1)) {
> +          std::vector<char> str(length + 1);
> +          ss = str.data();
> +          std::wcstombs((char *)ss, ws, str.size());
> +        } else {
> +          ss = s;
> +        }
> +#endif
>         return static_cast<basic_filebuf*>(
> -          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> +          my_base_type::open(ss, mode)
>           );

Yes.  It makes sense to convert from utf-8 to code page when we are not using the wide apis.
This would at least give you support for the current code page, beyond ascii.   Beyond that, the wide functions should be used.
Which compiler are you trying to support here, which doesn't give a wide open()?


>       }
>   };
> diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> index 2b93e69..208e725 100644
> --- a/Source/kwsys/ProcessWin32.c
> +++ b/Source/kwsys/ProcessWin32.c
> @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
>   /* ------------- Data managed per call to Execute ------------- */
> 
>   /* Buffer for data read in this pipe's thread.  */
> -  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> +  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];

This "*2" assumes all characters cmake sees will fit in the Basic Multilingual Plane.
Are we OK assuming that?
If the conversion from a code page to utf-16 results in surrogate pairs, there may not be enough space.


> 
>   /* The length of the data stored in the buffer.  */
>   DWORD DataLength;
> @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp,
> kwsysProcessPipeData* td)
>       KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
>       }
> 
> +    if (td->DataLength > 0) {
> +        UINT codepage = GetConsoleCP();
> +        if (!codepage) {
> +            codepage = GetACP();


Can this be stored in kwsysProcessCreateInformation, and not computed ever time we read data?



> +        }
> +        if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
> +            int wlength = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, NULL, 0);
> +            wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
> +            int r = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, wdata, wlength);
> +            if (r > 0) {
> +                r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0,
> wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
> +                if (r > 0) {
> +                    td->DataLength = r;
> +                }
> +            }
> +            free(wdata);
> +        }
> +    }

How about avoiding a malloc()/free() each time we read an array?

ProcessWin32.c already uses Encoding.h.  How about using the Encoding instead of 
WideCharToMultiByte(...)?  I'm fine either way.


Thanks for looking into this.
I had experimented with some of this as a next step, but didn't finish it.
Your general approach seems correct.

Clint

From chrisbux at gmail.com  Sat Jul  2 14:21:31 2016
From: chrisbux at gmail.com (Chris Bux)
Date: Sat, 2 Jul 2016 14:21:31 -0400
Subject: [cmake-developers] Green Hills MULTI Generator Recommendations
Message-ID: <CAAAjsBoLPf9_ajf=td1_XwEX4mVUVfo2Q-pdascyotMyjcMxJQ@mail.gmail.com>

I am interested in using CMake with Green Hills MULTI.  I see that there is
some experimental support for MULTI in CMake already, but that support
appears to be tied to ARM and assumes the Green Hills INTEGRITY RTOS is
also being used.  I would also like to build for the x86 and Renesas V850
architectures.

I have hacked in support for other targets just to get something working
locally, but I could use some recommendations on how to proceed so I can
submit patches to the CMake project.

I have a couple of questions.

1. GHS MULTI supports multiple processor architectures, but each of the
architectures use different compiler/linker names.  As an example, ARM uses
ccarm/cxarm but the v850 uses ccv850/cxv850.  Should the MULTI generator
provide a list of known compiler names by architecture, or should we rely
on users to set the appropriate CMAKE_<LANG>_COMPILER variables in the
toolchain file? If the generator should provide a list of known compiler
names, would CMake's -A option be the appropriate way to specify the target
processor's platform?  Is there another compiler toolchain that might be a
good template to copy from?

2. Is there a way in a toolchain file or on the command line to specify the
directory where CMake should look for the compiler executables?  I tried
creating a variable in a toolchain file, but it appears that CMake tries to
figure out the CMAKE_<LANG>_COMPILER value before the toolchain variable I
created is available.

3. Is there a way to specify the make executable full path in the toolchain
file?  GHS MULTI uses their own program called gbuild to drive their
builds.  At least for our team, it would not be a good idea for us to put
the gbuild executable in the PATH variable because we will be working with
more than one architecture and we would need to specify exactly which
gbuild executable to use - we wouldn't want the ARM gbuild to run when we
are building for x86.  I tried setting CMAKE_MAKE_PROGRAM in the toolchain
file, but the CMAKE_MAKE_PROGRAM variable I set in the toolchain file does
not appear to be available at the time FindMakeProgram() in the generator
is called.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160702/96341d07/attachment.html>

From davispuh at gmail.com  Sat Jul  2 19:48:33 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Sun, 3 Jul 2016 02:48:33 +0300
Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows
In-Reply-To: <2045206281.125728767.1467413666925.JavaMail.zimbra@elemtech.com>
References: <20160701021813.28657-1-davispuh@gmail.com>
 <2045206281.125728767.1467413666925.JavaMail.zimbra@elemtech.com>
Message-ID: <CAOE4rSyfGoy8zKPQDFoiEp2KGRYr2nrCW_-TUhRqy0VVDcAi2g@mail.gmail.com>

2016-07-01 17:41 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:

>
> Since you already have "bool SystemTools::GetEnv(const char* key,
> std::string& result)", another option would be to use it everywhere and
> maybe introduce something like "bool SystemTools::HasEnv(const char*
> key)" for those several cases where you only need to check the existence.
>
>
I implemented this, it's actually really nice API to work with.


2016-07-02 1:54 GMT+03:00 <clinton at elemtech.com>:

>
> ...
>
> > +#if defined(_WIN32)
> > +  // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> > +  // (and all other std::w*) fails once it encounters non-ASCII
> > +  // string unless locale is set.
> > +  // Note that even with this, seems it can't output characters
> > +  // which aren't present in ANSI codepage no matter what encoding
> > +  // is used for console.
> > +  // Also once any character outside of ANSI codepage is tried to
> > +  // be outputed then after there anymore won't be output from
> > +  // any of std::w* functions.
> > +  _wsetlocale(LC_ALL, L"");
> > +#endif
>
> The _wsetlocale() may be a problem.
>
> See:
> https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
> https://cmake.org/Bug/view.php?id=16099
>
>
>
Indeed, good catch, thanks, I didn't thought about this. But even now
most these locale aware functions like tolower/toupper and others are
wrong because internally we use UTF-8 and there 1 character can take
more than 1 byte so these functions won't work correctly for some strings
even if we don't set any locale.
Now here we actually set it only on Windows because there just isn't any
other way. Without setting locale we get only ASCII support and can't
output even ANSI characters. With locale we can atleast output ANSI
characters.
Currently Microsoft C++ library doesn't support UTF-8/UTF-16 locales.
Only way to output Unicode would be implement our own std::wcout which
would use wide WinAPI to write to console.

Anyway quick fix is to always use English locale then number parsing
will be expected and set user's codepage.

  std::wstring locale = L"English_United States.";
  locale += std::to_wstring(GetACP());
  _wsetlocale(LC_ALL, locale.c_str());


Of course proper Unicode support will be needed some day, but for now
this is still an improvement.


> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
> >       typedef std::basic_filebuf<CharType,Traits> my_base_type;
> >       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
> >       {
> > +        std::wstring wstr = Encoding::ToWide(s);
> > +        const wchar_t *ws = wstr.c_str();
> > +#if defined(_MSC_VER) && _MSC_VER >= 1400
> > +        const wchar_t *ss = ws;
> > +#else
> > +        const char *ss = 0;
> > +        size_t length = std::wcstombs(0, ws, 0);
> > +        if (length != size_t(-1)) {
> > +          std::vector<char> str(length + 1);
> > +          ss = str.data();
> > +          std::wcstombs((char *)ss, ws, str.size());
> > +        } else {
> > +          ss = s;
> > +        }
> > +#endif
> >         return static_cast<basic_filebuf*>(
> > -          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> > +          my_base_type::open(ss, mode)
> >           );
>
> Yes.  It makes sense to convert from utf-8 to code page when we are not
> using the wide apis.
> This would at least give you support for the current code page, beyond
> ascii.   Beyond that, the wide functions should be used.
> Which compiler are you trying to support here, which doesn't give a wide
> open()?
>
>
Only MSVC have ofstream::open(const wchar_t *) so for MinGW need to use
ofstream::open(const char *) or use wofstream::open(const wchar_t *) which
would
require quite big changes.


> >       }
> >   };
> > diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> > index 2b93e69..208e725 100644
> > --- a/Source/kwsys/ProcessWin32.c
> > +++ b/Source/kwsys/ProcessWin32.c
> > @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
> >   /* ------------- Data managed per call to Execute ------------- */
> >
> >   /* Buffer for data read in this pipe's thread.  */
> > -  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> > +  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];
>
> This "*2" assumes all characters cmake sees will fit in the Basic
> Multilingual Plane.
> Are we OK assuming that?
> If the conversion from a code page to utf-16 results in surrogate pairs,
> there may not be enough space.
>
>
Not really, it assumes character string from ANSI code page encoded
to internal encoding (UTF-8) will not take more than 2x space. Which I
think is a pretty good guess, because here we're processing output
from a process and so output will be paths and texts usually in
ASCII with not many characters which would require more than 2 bytes.
And it will still work if say 1/4th uses 4 bytes and 1 byte for rest 3/4th.

1024 * 1/4 * 4 bytes + 1024 * 3/4 * 1 byte (1792) < 1024 * 2 (2048)

But of course can increase it to 4x, only I think it's very unlikely
that it will be used.


>
> >
> >   /* The length of the data stored in the buffer.  */
> >   DWORD DataLength;
> > @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess*
> cp,
> > kwsysProcessPipeData* td)
> >       KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
> >       }
> >
> > +    if (td->DataLength > 0) {
> > +        UINT codepage = GetConsoleCP();
> > +        if (!codepage) {
> > +            codepage = GetACP();
>
>
> Can this be stored in kwsysProcessCreateInformation, and not computed ever
> time we read data?
>
>
>
Not kwsysProcessCreateInformation, because we can't access it from this
function, but
we can use kwsysProcess and I'll change to that.


>
> > +        }
> > +        if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
> > +            int wlength = MultiByteToWideChar(codepage, 0,
> td->DataBuffer,
> > td->DataLength, NULL, 0);
> > +            wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
> > +            int r = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> > td->DataLength, wdata, wlength);
> > +            if (r > 0) {
> > +                r =
> WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0,
> > wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL,
> NULL);
> > +                if (r > 0) {
> > +                    td->DataLength = r;
> > +                }
> > +            }
> > +            free(wdata);
> > +        }
> > +    }
>
> How about avoiding a malloc()/free() each time we read an array?
>
>
I don't really understand what you mean, I used malloc there because we
can't know beforehand how many bytes we actually will need before DataBuffer
is filled. Also I don't see there any array reading. All process output is
read with
single ReadFile call so I don't see how malloc could cause any overhead. Do
you
want that this buffer is added to kwsysProcessPipeData as static array?


> ProcessWin32.c already uses Encoding.h.  How about using the Encoding
> instead of
> WideCharToMultiByte(...)?  I'm fine either way.
>
>
There we get length from td->DataLength and so I assume we might get
non-null
terminated data in which case we can't use those Encoding functions because
they
expect source to be null-terminated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160703/b4efa4cd/attachment.html>

From davispuh at gmail.com  Sat Jul  2 20:29:41 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Sun,  3 Jul 2016 03:29:41 +0300
Subject: [cmake-developers] [PATCH v2] Improve encoding handling on Windows
Message-ID: <20160703002941.4330-1-davispuh@gmail.com>

On Windows getenv (and putenv) uses ANSI codepage so it needs to
be encoded to internally used encoding (eg. UTF-8). Here we use
_wgetenv (and _wputenv) instead and encode that.

Also typically Windows applications (eg. MSVC compiler) use current
console's codepage for output to pipes so we need to encode that
to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).

Next, when we're outputing to console need to use wide functions.

This change allows that compilers such as MSVC on Windows can be
installed in non-ASCII path and will work correctly for all
console's codepages which supports that path's characters.
---
 Source/CPack/cmCPackGenerator.cxx           |  8 +--
 Source/CTest/cmCTestCoverageHandler.cxx     | 12 ++--
 Source/CTest/cmCTestCurl.cxx                | 21 +++----
 Source/CTest/cmCTestMultiProcessHandler.cxx |  8 +--
 Source/cmBuildCommand.cxx                   | 23 +++----
 Source/cmCLocaleEnvironmentScope.cxx        |  4 +-
 Source/cmCTest.cxx                          | 11 ++--
 Source/cmCommandArgumentParserHelper.cxx    |  8 +--
 Source/cmConditionEvaluator.cxx             |  2 +-
 Source/cmExportCommand.cxx                  |  5 +-
 Source/cmExtraEclipseCDT4Generator.cxx      |  9 +--
 Source/cmFileCommand.cxx                    | 12 ++--
 Source/cmFindPackageCommand.cxx             |  4 +-
 Source/cmGlobalVisualStudio7Generator.cxx   |  6 +-
 Source/cmMakefile.cxx                       |  5 +-
 Source/cmNinjaTargetGenerator.cxx           |  2 +-
 Source/cmQtAutoGenerators.cxx               |  2 +-
 Source/cmSetCommand.cxx                     |  6 +-
 Source/cmState.cxx                          |  5 +-
 Source/cmSystemTools.cxx                    | 11 +++-
 Source/cmTimestamp.cxx                      |  7 +--
 Source/cmake.cxx                            | 16 ++---
 Source/cmakemain.cxx                        | 38 ++++++++++-
 Source/cmcmd.cxx                            | 12 ++--
 Source/kwsys/CMakeLists.txt                 |  2 +
 Source/kwsys/Directory.cxx                  |  2 +-
 Source/kwsys/FStream.hxx.in                 | 19 +++++-
 Source/kwsys/ProcessWin32.c                 | 25 +++++++-
 Source/kwsys/SystemInformation.cxx          | 20 +++---
 Source/kwsys/SystemTools.cxx                | 98 +++++++++++++++++++----------
 Source/kwsys/SystemTools.hxx.in             |  4 +-
 Source/kwsys/testSystemTools.cxx            |  9 +--
 32 files changed, 260 insertions(+), 156 deletions(-)

diff --git a/Source/CPack/cmCPackGenerator.cxx b/Source/CPack/cmCPackGenerator.cxx
index df8bb0f..76609e1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1074,11 +1074,11 @@ const char* cmCPackGenerator::GetInstallPath()
     return this->InstallPath.c_str();
   }
 #if defined(_WIN32) && !defined(__CYGWIN__)
-  const char* prgfiles = cmsys::SystemTools::GetEnv("ProgramFiles");
-  const char* sysDrive = cmsys::SystemTools::GetEnv("SystemDrive");
-  if (prgfiles) {
+  std::string prgfiles;
+  std::string sysDrive;
+  if (cmsys::SystemTools::GetEnv("ProgramFiles", prgfiles)) {
     this->InstallPath = prgfiles;
-  } else if (sysDrive) {
+  } else if (cmsys::SystemTools::GetEnv("SystemDrive", sysDrive)) {
     this->InstallPath = sysDrive;
     this->InstallPath += "/Program Files";
   } else {
diff --git a/Source/CTest/cmCTestCoverageHandler.cxx b/Source/CTest/cmCTestCoverageHandler.cxx
index 7102533..9410a52 100644
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@ -727,10 +727,7 @@ int cmCTestCoverageHandler::HandleCoberturaCoverage(
   // if it doesn't exist or is empty, assume the
   // binary directory is used.
   std::string coverageXMLFile;
-  const char* covDir = cmSystemTools::GetEnv("COBERTURADIR");
-  if (covDir && strlen(covDir) != 0) {
-    coverageXMLFile = std::string(covDir);
-  } else {
+  if (!cmSystemTools::GetEnv("COBERTURADIR", coverageXMLFile) || coverageXMLFile.empty()) {
     coverageXMLFile = this->CTest->GetBinaryDir();
   }
   // build the find file string with the directory from above
@@ -791,7 +788,8 @@ struct cmCTestCoverageHandlerLocale
 {
   cmCTestCoverageHandlerLocale()
   {
-    if (const char* l = cmSystemTools::GetEnv("LC_ALL")) {
+    std::string l;
+    if (cmSystemTools::GetEnv("LC_ALL", l)) {
       lc_all = l;
     }
     if (lc_all != "C") {
@@ -2121,8 +2119,8 @@ int cmCTestCoverageHandler::RunBullseyeSourceSummary(
 int cmCTestCoverageHandler::HandleBullseyeCoverage(
   cmCTestCoverageHandlerContainer* cont)
 {
-  const char* covfile = cmSystemTools::GetEnv("COVFILE");
-  if (!covfile || strlen(covfile) == 0) {
+  std::string covfile;
+  if (!cmSystemTools::GetEnv("COVFILE", covfile) || covfile.empty()) {
     cmCTestOptionalLog(this->CTest, HANDLER_VERBOSE_OUTPUT,
                        " COVFILE environment variable not found, not running "
                        " bullseye\n",
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index 6b8e5b5..19f32c8 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -219,16 +219,16 @@ bool cmCTestCurl::HttpRequest(std::string const& url,
 
 void cmCTestCurl::SetProxyType()
 {
-  if (cmSystemTools::GetEnv("HTTP_PROXY")) {
-    this->HTTPProxy = cmSystemTools::GetEnv("HTTP_PROXY");
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT")) {
+  if (cmSystemTools::GetEnv("HTTP_PROXY", this->HTTPProxy)) {
+    std::string port;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT", port)) {
       this->HTTPProxy += ":";
-      this->HTTPProxy += cmSystemTools::GetEnv("HTTP_PROXY_PORT");
+      this->HTTPProxy += port;
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE")) {
+    std::string type;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE", type)) {
       // this is the default
       this->HTTPProxyType = CURLPROXY_HTTP;
-      std::string type = cmSystemTools::GetEnv("HTTP_PROXY_TYPE");
       // HTTP/SOCKS4/SOCKS5
       if (type == "HTTP") {
         this->HTTPProxyType = CURLPROXY_HTTP;
@@ -238,12 +238,11 @@ void cmCTestCurl::SetProxyType()
         this->HTTPProxyType = CURLPROXY_SOCKS5;
       }
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_USER")) {
-      this->HTTPProxyAuth = cmSystemTools::GetEnv("HTTP_PROXY_USER");
-    }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD")) {
+    cmSystemTools::GetEnv("HTTP_PROXY_USER", this->HTTPProxyAuth);
+    std::string passwd;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD", passwd)) {
       this->HTTPProxyAuth += ":";
-      this->HTTPProxyAuth += cmSystemTools::GetEnv("HTTP_PROXY_PASSWD");
+      this->HTTPProxyAuth += passwd;
     }
   }
 }
diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx b/Source/CTest/cmCTestMultiProcessHandler.cxx
index ae97d32..ffd51c7 100644
--- a/Source/CTest/cmCTestMultiProcessHandler.cxx
+++ b/Source/CTest/cmCTestMultiProcessHandler.cxx
@@ -261,12 +261,12 @@ void cmCTestMultiProcessHandler::StartNextTests()
     allTestsFailedTestLoadCheck = true;
 
     // Check for a fake load average value used in testing.
-    if (const char* fake_load_value =
-          cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING")) {
+    std::string fake_load_value;
+    if (cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING", fake_load_value)) {
       usedFakeLoadForTesting = true;
-      if (!cmSystemTools::StringToULong(fake_load_value, &systemLoad)) {
+      if (!cmSystemTools::StringToULong(fake_load_value.c_str(), &systemLoad)) {
         cmSystemTools::Error("Failed to parse fake load value: ",
-                             fake_load_value);
+                             fake_load_value.c_str());
       }
     }
     // If it's not set, look up the true load average.
diff --git a/Source/cmBuildCommand.cxx b/Source/cmBuildCommand.cxx
index fb143a2..d29c31f 100644
--- a/Source/cmBuildCommand.cxx
+++ b/Source/cmBuildCommand.cxx
@@ -36,8 +36,8 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   const char* variable = args[0].c_str();
 
   // Parse remaining arguments.
-  const char* configuration = CM_NULLPTR;
-  const char* project_name = CM_NULLPTR;
+  std::string configuration;
+  std::string project_name;
   std::string target;
   enum Doing
   {
@@ -56,10 +56,10 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
       doing = DoingTarget;
     } else if (doing == DoingConfiguration) {
       doing = DoingNone;
-      configuration = args[i].c_str();
+      configuration = args[i];
     } else if (doing == DoingProjectName) {
       doing = DoingNone;
-      project_name = args[i].c_str();
+      project_name = args[i];
     } else if (doing == DoingTarget) {
       doing = DoingNone;
       target = args[i];
@@ -76,14 +76,14 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   // so we put this code here to end up with the same default configuration
   // as the original 2-arg build_command signature:
   //
-  if (!configuration || !*configuration) {
-    configuration = getenv("CMAKE_CONFIG_TYPE");
+  if (configuration.empty()) {
+    cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configuration);
   }
-  if (!configuration || !*configuration) {
+  if (configuration.empty()) {
     configuration = "Release";
   }
 
-  if (project_name && *project_name) {
+  if (!project_name.empty()) {
     this->Makefile->IssueMessage(
       cmake::AUTHOR_WARNING,
       "Ignoring PROJECT_NAME option because it has no effect.");
@@ -91,7 +91,7 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
 
   std::string makecommand =
     this->Makefile->GetGlobalGenerator()->GenerateCMakeBuildCommand(
-      target, configuration, "", this->Makefile->IgnoreErrorsCMP0061());
+      target, configuration.c_str(), "", this->Makefile->IgnoreErrorsCMP0061());
 
   this->Makefile->AddDefinition(variable, makecommand.c_str());
 
@@ -109,10 +109,7 @@ bool cmBuildCommand::TwoArgsSignature(std::vector<std::string> const& args)
   const char* cacheValue = this->Makefile->GetDefinition(define);
 
   std::string configType = "Release";
-  const char* cfg = getenv("CMAKE_CONFIG_TYPE");
-  if (cfg && *cfg) {
-    configType = cfg;
-  }
+  cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configType);
 
   std::string makecommand =
     this->Makefile->GetGlobalGenerator()->GenerateCMakeBuildCommand(
diff --git a/Source/cmCLocaleEnvironmentScope.cxx b/Source/cmCLocaleEnvironmentScope.cxx
index a19dbae..5661cd9 100644
--- a/Source/cmCLocaleEnvironmentScope.cxx
+++ b/Source/cmCLocaleEnvironmentScope.cxx
@@ -31,8 +31,8 @@ cmCLocaleEnvironmentScope::cmCLocaleEnvironmentScope()
 
 std::string cmCLocaleEnvironmentScope::GetEnv(std::string const& key)
 {
-  const char* value = cmSystemTools::GetEnv(key);
-  return value ? value : std::string();
+  std::string value;
+  return cmSystemTools::GetEnv(key, value) ? value : std::string();
 }
 
 void cmCLocaleEnvironmentScope::SetEnv(std::string const& key,
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 9950a84..4eb4e3a 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -298,9 +298,9 @@ cmCTest::cmCTest()
   this->ComputedCompressMemCheckOutput = false;
   this->RepeatTests = 1; // default to run each test once
   this->RepeatUntilFail = false;
-  if (const char* outOnFail =
-        cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE")) {
-    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail);
+  std::string outOnFail;
+  if (cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE", outOnFail)) {
+    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail.c_str());
   }
   this->InitStreams();
 
@@ -2125,8 +2125,9 @@ int cmCTest::Run(std::vector<std::string>& args, std::string* output)
   } // the close of the for argument loop
 
   if (!this->ParallelLevelSetInCli) {
-    if (const char* parallel = cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL")) {
-      int plevel = atoi(parallel);
+    std::string parallel;
+    if (cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL", parallel)) {
+      int plevel = atoi(parallel.c_str());
       this->SetParallelLevel(plevel);
     }
   }
diff --git a/Source/cmCommandArgumentParserHelper.cxx b/Source/cmCommandArgumentParserHelper.cxx
index 294117c..42fb105 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -71,12 +71,12 @@ char* cmCommandArgumentParserHelper::ExpandSpecialVariable(const char* key,
     return this->EmptyVariable;
   }
   if (strcmp(key, "ENV") == 0) {
-    char* ptr = getenv(var);
-    if (ptr) {
+    std::string str;
+    if (cmSystemTools::GetEnv(var, str)) {
       if (this->EscapeQuotes) {
-        return this->AddString(cmSystemTools::EscapeQuotes(ptr));
+        return this->AddString(cmSystemTools::EscapeQuotes(str.c_str()));
       } else {
-        return ptr;
+        return this->AddString(str);
       }
     }
     return this->EmptyVariable;
diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 67b2571..e02221c 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -486,7 +486,7 @@ bool cmConditionEvaluator::HandleLevel1(cmArgumentList& newArgs, std::string&,
         if (argP1len > 4 && argP1->GetValue().substr(0, 4) == "ENV{" &&
             argP1->GetValue().operator[](argP1len - 1) == '}') {
           std::string env = argP1->GetValue().substr(4, argP1len - 5);
-          bdef = cmSystemTools::GetEnv(env.c_str()) ? true : false;
+          bdef = cmSystemTools::HasEnv(env.c_str());
         } else {
           bdef = this->Makefile.IsDefinitionSet(argP1->GetValue());
         }
diff --git a/Source/cmExportCommand.cxx b/Source/cmExportCommand.cxx
index 3cb575e..fc62492 100644
--- a/Source/cmExportCommand.cxx
+++ b/Source/cmExportCommand.cxx
@@ -327,11 +327,10 @@ void cmExportCommand::StorePackageRegistryDir(std::string const& package,
   fname += "/cmake/packages/";
   fname += package;
 #else
-  const char* home = cmSystemTools::GetEnv("HOME");
-  if (!home) {
+  std::string fname;
+  if (!cmSystemTools::GetEnv("HOME", fname)) {
     return;
   }
-  std::string fname = home;
   cmSystemTools::ConvertToUnixSlashes(fname);
   fname += "/.cmake/packages/";
   fname += package;
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx
index 16cb082..af09cd6 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -208,7 +208,8 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
   // get the variables from the environment and from the cache and then
   // figure out which one to use:
 
-  const char* envVarValue = getenv(envVar);
+  std::string envVarValue;
+  bool envVarSet = cmSystemTools::GetEnv(envVar, envVarValue);
 
   std::string cacheEntryName = "CMAKE_ECLIPSE_ENVVAR_";
   cacheEntryName += envVar;
@@ -217,17 +218,17 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
 
   // now we have both, decide which one to use
   std::string valueToUse;
-  if (envVarValue == CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  if (!envVarSet && cacheValue == CM_NULLPTR) {
     // nothing known, do nothing
     valueToUse = "";
-  } else if (envVarValue != CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  } else if (envVarSet && cacheValue == CM_NULLPTR) {
     // The variable is in the env, but not in the cache. Use it and put it
     // in the cache
     valueToUse = envVarValue;
     mf->AddCacheDefinition(cacheEntryName, valueToUse.c_str(),
                            cacheEntryName.c_str(), cmState::STRING, true);
     mf->GetCMakeInstance()->SaveCache(lg->GetBinaryDirectory());
-  } else if (envVarValue == CM_NULLPTR && cacheValue != CM_NULLPTR) {
+  } else if (!envVarSet && cacheValue != CM_NULLPTR) {
     // It is already in the cache, but not in the env, so use it from the cache
     valueToUse = cacheValue;
   } else {
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 5a1238b..def137e 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -1609,8 +1609,11 @@ struct cmFileInstaller : public cmFileCopier
     // Installation does not use source permissions by default.
     this->UseSourcePermissions = false;
     // Check whether to copy files always or only if they have changed.
-    this->Always =
-      cmSystemTools::IsOn(cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS"));
+     std::string install_always;
+     if (cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS", install_always)) {
+      this->Always =
+        cmSystemTools::IsOn(install_always.c_str());
+     }
     // Get the current manifest.
     this->Manifest =
       this->Makefile->GetSafeDefinition("CMAKE_INSTALL_MANIFEST_FILES");
@@ -1869,9 +1872,8 @@ bool cmFileInstaller::HandleInstallDestination()
     return false;
   }
 
-  const char* destdir = cmSystemTools::GetEnv("DESTDIR");
-  if (destdir && *destdir) {
-    std::string sdestdir = destdir;
+  std::string sdestdir;
+  if (cmSystemTools::GetEnv("DESTDIR", sdestdir) && !sdestdir.empty()) {
     cmSystemTools::ConvertToUnixSlashes(sdestdir);
     char ch1 = destination[0];
     char ch2 = destination[1];
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index d5fd75d..260079b 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1077,8 +1077,8 @@ void cmFindPackageCommand::FillPrefixesUserRegistry()
                                  this->LabeledPaths[PathLabel::UserRegistry]);
   }
 #else
-  if (const char* home = cmSystemTools::GetEnv("HOME")) {
-    std::string dir = home;
+  std::string dir;
+  if (cmSystemTools::GetEnv("HOME", dir)) {
     dir += "/.cmake/packages/";
     dir += this->Name;
     this->LoadPackageRegistryDir(dir,
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx b/Source/cmGlobalVisualStudio7Generator.cxx
index 262909f..0a83b3a 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -122,9 +122,9 @@ void cmGlobalVisualStudio7Generator::EnableLanguage(
   // does not use the environment it is run in, and this allows
   // for running commands and using dll's that the IDE environment
   // does not know about.
-  const char* extraPath = cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH");
-  if (extraPath) {
-    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath,
+  std::string extraPath;
+  if (cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH", extraPath)) {
+    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath.c_str(),
                            "Saved environment variable CMAKE_MSVCIDE_RUN_PATH",
                            cmState::STATIC);
   }
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 0d550dd..ab7de57 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2572,6 +2572,7 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
           std::string const& lookup = result.substr(var.loc);
           const char* value = CM_NULLPTR;
           std::string varresult;
+          std::string svalue;
           static const std::string lineVar = "CMAKE_CURRENT_LIST_LINE";
           switch (var.domain) {
             case NORMAL:
@@ -2584,7 +2585,9 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
               }
               break;
             case ENVIRONMENT:
-              value = cmSystemTools::GetEnv(lookup.c_str());
+              if (cmSystemTools::GetEnv(lookup, svalue)) {
+                value = svalue.c_str();
+              }
               break;
             case CACHE:
               value = state->GetCacheEntryValue(lookup);
diff --git a/Source/cmNinjaTargetGenerator.cxx b/Source/cmNinjaTargetGenerator.cxx
index 1d3e608..855a243 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -741,5 +741,5 @@ bool cmNinjaTargetGenerator::ForceResponseFile()
 {
   static std::string const forceRspFile = "CMAKE_NINJA_FORCE_RESPONSE_FILE";
   return (this->GetMakefile()->IsDefinitionSet(forceRspFile) ||
-          cmSystemTools::GetEnv(forceRspFile) != CM_NULLPTR);
+          cmSystemTools::HasEnv(forceRspFile));
 }
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 4b40c08..b821fda 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -88,7 +88,7 @@ static std::string extractSubDir(const std::string& absPath,
 }
 
 cmQtAutoGenerators::cmQtAutoGenerators()
-  : Verbose(cmsys::SystemTools::GetEnv("VERBOSE") != CM_NULLPTR)
+  : Verbose(cmsys::SystemTools::HasEnv("VERBOSE"))
   , ColorOutput(true)
   , RunMocFailed(false)
   , RunUicFailed(false)
diff --git a/Source/cmSetCommand.cxx b/Source/cmSetCommand.cxx
index 1484368..bbea89f 100644
--- a/Source/cmSetCommand.cxx
+++ b/Source/cmSetCommand.cxx
@@ -31,7 +31,11 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
     putEnvArg += "=";
 
     // what is the current value if any
-    const char* currValue = getenv(varName);
+    std::string scurrValue;
+    const char* currValue = 0;
+    if (cmSystemTools::GetEnv(varName, scurrValue)) {
+      currValue = scurrValue.c_str();
+    }
     delete[] varName;
 
     // will it be set to something, then set it
diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index f2fe134..0470508 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -1286,8 +1286,9 @@ void cmState::Snapshot::SetDefaultDefinitions()
   this->SetDefinition("CMAKE_HOST_UNIX", "1");
 #endif
 #if defined(__CYGWIN__)
-  if (cmSystemTools::IsOn(
-        cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32"))) {
+  std::string legacy;
+  if (cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32", legacy) &&
+      cmSystemTools::IsOn(legacy.c_str())) {
     this->SetDefinition("WIN32", "1");
     this->SetDefinition("CMAKE_HOST_WIN32", "1");
   }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 2d463f3..5656c30 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -333,7 +333,12 @@ void cmSystemTools::Message(const char* m1, const char* title)
                          s_MessageCallbackClientData);
     return;
   } else {
+#if defined(_WIN32)
+    std::wstring wm1 = cmsys::Encoding::ToWide(m1);
+    std::wcerr << wm1 << std::endl << std::flush;
+#else
     std::cerr << m1 << std::endl << std::flush;
+#endif
   }
 }
 
@@ -2069,9 +2074,9 @@ void cmSystemTools::MakefileColorEcho(int color, const char* message,
   // However, we can test for some situations when the answer is most
   // likely no.
   int assumeTTY = cmsysTerminal_Color_AssumeTTY;
-  if (cmSystemTools::GetEnv("DART_TEST_FROM_DART") ||
-      cmSystemTools::GetEnv("DASHBOARD_TEST_FROM_CTEST") ||
-      cmSystemTools::GetEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
+  if (cmSystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      cmSystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST") ||
+      cmSystemTools::HasEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
     // Avoid printing color escapes during dashboard builds.
     assumeTTY = 0;
   }
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index c3c1d17..61b74db 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -93,10 +93,9 @@ time_t cmTimestamp::CreateUtcTimeTFromTm(struct tm& tm) const
 #else
   // From Linux timegm() manpage.
 
-  std::string tz_old = "TZ=";
-  if (const char* tz = cmSystemTools::GetEnv("TZ")) {
-    tz_old += tz;
-  }
+  std::string tz_old = "";
+  cmSystemTools::GetEnv("TZ", tz_old);
+  tz_old = "TZ=" + tz_old;
 
   // The standard says that "TZ=" or "TZ=[UNRECOGNIZED_TZ]" means UTC.
   // It seems that "TZ=" does NOT work, at least under Windows
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index c597605..1fe881c 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -955,16 +955,10 @@ void cmake::SetGlobalGenerator(cmGlobalGenerator* gg)
   cmSystemTools::SetForceUnixPaths(this->GlobalGenerator->GetForceUnixPaths());
 
   // Save the environment variables CXX and CC
-  const char* cxx = getenv("CXX");
-  const char* cc = getenv("CC");
-  if (cxx) {
-    this->CXXEnvironment = cxx;
-  } else {
+  if (!cmSystemTools::GetEnv("CXX", this->CXXEnvironment)) {
     this->CXXEnvironment = "";
   }
-  if (cc) {
-    this->CCEnvironment = cc;
-  } else {
+  if (!cmSystemTools::GetEnv("CC", this->CCEnvironment)) {
     this->CCEnvironment = "";
   }
 }
@@ -1429,7 +1423,7 @@ int cmake::Run(const std::vector<std::string>& args, bool noconfigure)
   // should fail (if "-i" is an option).  We cannot simply test
   // whether "-i" is given and remove it because some make programs
   // encode the MAKEFLAGS variable in a strange way.
-  if (getenv("MAKEFLAGS")) {
+  if (cmSystemTools::HasEnv("MAKEFLAGS")) {
     cmSystemTools::PutEnv("MAKEFLAGS=");
   }
 
@@ -1708,8 +1702,8 @@ int cmake::CheckBuildSystem()
   // the make system's VERBOSE environment variable to enable verbose
   // output. This can be skipped by setting CMAKE_NO_VERBOSE (which is set
   // by the Eclipse and KDevelop generators).
-  bool verbose = ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-                  (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+  bool verbose = ((cmSystemTools::HasEnv("VERBOSE")) &&
+                  (!cmSystemTools::HasEnv("CMAKE_NO_VERBOSE")));
 
   // This method will check the integrity of the build system if the
   // option was given on the command line.  It reads the given file to
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index 521a5bf..efc6d52 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -127,7 +127,13 @@ static std::string cmakemainGetStack(void* clientdata)
 static void cmakemainMessageCallback(const char* m, const char*, bool&,
                                      void* clientdata)
 {
+#if defined(_WIN32)
+  std::wstring wm = cmsys::Encoding::ToWide(m);
+  std::wstring wstack = cmsys::Encoding::ToWide(cmakemainGetStack(clientdata).c_str());
+  std::wcerr << wm << wstack << std::endl << std::flush;
+#else
   std::cerr << m << cmakemainGetStack(clientdata) << std::endl << std::flush;
+#endif
 }
 
 static void cmakemainProgressCallback(const char* m, float prog,
@@ -144,15 +150,41 @@ static void cmakemainProgressCallback(const char* m, float prog,
   }
 
   if ((prog < 0) || (!dir.empty())) {
+#if defined(_WIN32)
+    std::wstring wm = cmsys::Encoding::ToWide(m);
+    std::wstring wdir = cmsys::Encoding::ToWide(dir.c_str());
+    std::wstring wstack = cmsys::Encoding::ToWide(cmakemainGetStack(clientdata).c_str());
+    std::wcout << L"-- " << wm << wdir << wstack << std::endl << std::flush;
+#else
     std::cout << "-- " << m << dir << cmakemainGetStack(clientdata)
-              << std::endl;
+              << std::endl << std::flush;
+#endif
   }
-
-  std::cout.flush();
 }
 
 int main(int ac, char const* const* av)
 {
+#if defined(_WIN32)
+  // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
+  // (and all other std::w*) fails once it encounters non-ASCII
+  // string unless locale is set.
+  // Note that even with this, seems it can't output characters
+  // which aren't present in ANSI codepage no matter what encoding
+  // is used for console.
+  // Currently Microsoft's C++ library doesn't support UTF-8/UTF-16
+  // locales so we can only set and output in users's ANSI codepage.
+  // Also once any character outside of ANSI codepage is tried to
+  // be outputed then after there anymore won't be output from
+  // any of std::w* functions.
+  // We need to explictly set English locale because with other
+  // locales number parsing can differ.
+  // Can't use ".ACP" as it would be ANSI codepage for locale
+  // we're setting not the one user uses so we manually set user's
+  // codepage.
+  std::wstring locale = L"English_United States.";
+  locale += std::to_wstring(GetACP());
+  _wsetlocale(LC_ALL, locale.c_str());
+#endif
   cmsys::Encoding::CommandLineArguments args =
     cmsys::Encoding::CommandLineArguments::Main(ac, av);
   ac = args.argc();
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 010a3b2..d97d72d 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -701,8 +701,8 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
       // verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
       // (which is set by the Eclipse and KDevelop generators).
       bool verbose =
-        ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-         (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+        ((cmSystemTools::HasEnv("VERBOSE")) &&
+         (!cmSystemTools::HasEnv("CMAKE_NO_VERBOSE")));
 
       // Create a cmake object instance to process dependencies.
       cmake cm;
@@ -900,9 +900,9 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
         // 1/10th of a second after the untar.  If CMAKE_UNTAR_DELAY
         // is set in the env, its value will be used instead of 100.
         int delay = 100;
-        const char* delayVar = cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY");
-        if (delayVar) {
-          delay = atoi(delayVar);
+        std::string delayVar;
+        if (cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY", delayVar)) {
+          delay = atoi(delayVar.c_str());
         }
         if (delay) {
           cmSystemTools::Delay(delay);
@@ -1254,7 +1254,7 @@ int cmcmd::VisualStudioLink(std::vector<std::string>& args, int type)
   if (args.size() < 2) {
     return -1;
   }
-  bool verbose = cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR;
+  bool verbose = cmSystemTools::HasEnv("VERBOSE");
   std::vector<std::string> expandedArgs;
   for (std::vector<std::string>::iterator i = args.begin(); i != args.end();
        ++i) {
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 8b15394..cab7f38 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -709,6 +709,8 @@ IF(KWSYS_USE_Process)
   IF(NOT UNIX)
     # Use the Windows implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessWin32.c)
+    SET_PROPERTY(SOURCE ProcessWin32.c APPEND PROPERTY COMPILE_DEFINITIONS
+      KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
   ELSE()
     # Use the UNIX implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessUNIX.c)
diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx
index c549792..659c559 100644
--- a/Source/kwsys/Directory.cxx
+++ b/Source/kwsys/Directory.cxx
@@ -86,7 +86,7 @@ void Directory::Clear()
 
 // First microsoft compilers
 
-#if defined(_MSC_VER) || defined(__WATCOMC__)
+#if defined(_WIN32) || defined(__WATCOMC__)
 #include <windows.h>
 #include <io.h>
 #include <ctype.h>
diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in
index 681e4d8..842148d 100644
--- a/Source/kwsys/FStream.hxx.in
+++ b/Source/kwsys/FStream.hxx.in
@@ -17,7 +17,7 @@
 
 namespace @KWSYS_NAMESPACE@
 {
-#if defined(_MSC_VER) && _MSC_VER >= 1400
+#if defined(_WIN32)
 # if defined(_NOEXCEPT)
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT _NOEXCEPT
 # else
@@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
       typedef std::basic_filebuf<CharType,Traits> my_base_type;
       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
       {
+        std::wstring wstr = Encoding::ToWide(s);
+        const wchar_t *ws = wstr.c_str();
+#if defined(_MSC_VER) && _MSC_VER >= 1400
+        const wchar_t *ss = ws;
+#else
+        const char *ss = 0;
+        size_t length = std::wcstombs(0, ws, 0);
+        if (length != size_t(-1)) {
+          std::vector<char> str(length + 1);
+          ss = str.data();
+          std::wcstombs((char *)ss, ws, str.size());
+        } else {
+          ss = s;
+        }
+#endif
         return static_cast<basic_filebuf*>(
-          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
+          my_base_type::open(ss, mode)
           );
       }
   };
diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
index 2b93e69..da21cca 100644
--- a/Source/kwsys/ProcessWin32.c
+++ b/Source/kwsys/ProcessWin32.c
@@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
   /* ------------- Data managed per call to Execute ------------- */
 
   /* Buffer for data read in this pipe's thread.  */
-  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
+  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];
 
   /* The length of the data stored in the buffer.  */
   DWORD DataLength;
@@ -319,6 +319,9 @@ struct kwsysProcess_s
   /* Own handles for the child's ends of the pipes in the parent process.
      Used temporarily during process creation.  */
   HANDLE PipeChildStd[3];
+
+  /* Console's active codepage */
+  UINT codepage;
 };
 
 /*--------------------------------------------------------------------------*/
@@ -1626,6 +1629,21 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp, kwsysProcessPipeData* td)
       KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
       }
 
+    if (td->DataLength > 0) {
+      if (cp->codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
+        int wlength = MultiByteToWideChar(cp->codepage, 0, td->DataBuffer, td->DataLength, NULL, 0);
+        wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
+        int r = MultiByteToWideChar(cp->codepage, 0, td->DataBuffer, td->DataLength, wdata, wlength);
+        if (r > 0) {
+          r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0, wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
+          if (r > 0) {
+            td->DataLength = r;
+          }
+        }
+        free(wdata);
+      }
+    }
+
     KWSYSPE_DEBUG((stderr, "read %d\n", td->Index));
 
     /* Wait for our turn to be handled by the main thread.  */
@@ -1761,6 +1779,11 @@ int kwsysProcessInitialize(kwsysProcess* cp)
     }
   }
 
+  cp->codepage = GetConsoleCP();
+  if (!cp->codepage) {
+    cp->codepage = GetACP();
+  }
+
   return 1;
 }
 
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 81fb2f9..1af7bdb 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType;
 # define USE_CPUID 0
 #endif
 
+#include <cmsys/SystemTools.hxx>
+
 #if USE_CPUID
 
 #define CPUID_AWARE_COMPILER
@@ -3476,10 +3478,10 @@ SystemInformationImplementation::GetHostMemoryAvailable(const char *hostLimitEnv
   // apply a limit across a set of processes. Units are in KiB.
   if (hostLimitEnvVarName)
     {
-    const char *hostLimitEnvVarValue=getenv(hostLimitEnvVarName);
-    if (hostLimitEnvVarValue)
+    std::string hostLimitEnvVarValue;
+    if (SystemTools::GetEnv(hostLimitEnvVarName, hostLimitEnvVarValue))
       {
-      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue);
+      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue.c_str());
       if (hostLimit>0)
         {
         memTotal=min(hostLimit,memTotal);
@@ -3506,10 +3508,10 @@ SystemInformationImplementation::GetProcMemoryAvailable(
   // are not employed. Units are in KiB.
   if (procLimitEnvVarName)
     {
-    const char *procLimitEnvVarValue=getenv(procLimitEnvVarName);
-    if (procLimitEnvVarValue)
+    std::string procLimitEnvVarValue;
+    if (SystemTools::GetEnv(procLimitEnvVarName, procLimitEnvVarValue))
       {
-      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue);
+      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue.c_str());
       if (procLimit>0)
         {
         memAvail=min(procLimit,memAvail);
@@ -5408,11 +5410,7 @@ bool SystemInformationImplementation::QueryOSInformation()
     }
   this->Hostname = name;
 
-  const char* arch = getenv("PROCESSOR_ARCHITECTURE");
-  if(arch)
-    {
-    this->OSPlatform = arch;
-    }
+  SystemTools::GetEnv("PROCESSOR_ARCHITECTURE", this->OSPlatform);
 
 #else
 
diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..c4a3311 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -421,14 +421,12 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
     {
     env = "PATH";
     }
-  const char* cpathEnv = SystemTools::GetEnv(env);
-  if ( !cpathEnv )
+  std::string pathEnv;
+  if ( !SystemTools::GetEnv(env, pathEnv) )
     {
     return;
     }
 
-  std::string pathEnv = cpathEnv;
-
   // A hack to make the below algorithm work.
   if(!pathEnv.empty() && *pathEnv.rbegin() != pathSep)
     {
@@ -456,22 +454,45 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
     }
 }
 
-const char* SystemTools::GetEnv(const char* key)
+bool SystemTools::GetEnv(const char* key, std::string& result)
 {
-  return getenv(key);
+#if defined(_WIN32)
+  std::wstring wkey = Encoding::ToWide(key);
+  wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+    result = Encoding::ToNarrow(wv);
+    return true;
+  }
+  return false;
+#else
+  const char* v = getenv(key);
+  if(v)
+    {
+    result = v;
+    return true;
+    }
+  else
+    {
+    return false;
+    }
+#endif
 }
 
-const char* SystemTools::GetEnv(const std::string& key)
+bool SystemTools::GetEnv(const std::string& key, std::string& result)
 {
-  return SystemTools::GetEnv(key.c_str());
+  return SystemTools::GetEnv(key.c_str(), result);
 }
 
-bool SystemTools::GetEnv(const char* key, std::string& result)
+bool SystemTools::HasEnv(const char* key)
 {
+#if defined(_WIN32)
+  std::wstring wkey = Encoding::ToWide(key);
+  wchar_t* v = _wgetenv(wkey.c_str());
+#else
   const char* v = getenv(key);
+#endif
   if(v)
     {
-    result = v;
     return true;
     }
   else
@@ -480,9 +501,9 @@ bool SystemTools::GetEnv(const char* key, std::string& result)
     }
 }
 
-bool SystemTools::GetEnv(const std::string& key, std::string& result)
+bool SystemTools::HasEnv(const std::string& key)
 {
-  return SystemTools::GetEnv(key.c_str(), result);
+  return SystemTools::HasEnv(key.c_str());
 }
 
 //----------------------------------------------------------------------------
@@ -533,13 +554,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  std::wstring wbuf = Encoding::ToWide(buf);
+  int r = _wputenv(wbuf.c_str());
+#else
+  int r = putenv(buf);
+#endif
+  if(r < 0)
     {
     err = errno;
     }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  std::wstring wbuf = Encoding::ToWide(buf);
+  int r = _wputenv(wbuf.c_str());
+#else
+  int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
     {
     err = errno;
     }
@@ -679,7 +712,12 @@ public:
     static_cast<void>(oldEnv);
     char* newEnv = strdup(env);
     this->insert(newEnv);
+#if defined(_WIN32)
+    std::wstring wEnv = Encoding::ToWide(newEnv);
+    return _wputenv(wEnv.c_str()) == 0;
+#else
     return putenv(newEnv) == 0;
+#endif
     }
   bool UnPut(const char* env)
     {
@@ -2044,8 +2082,8 @@ void SystemTools::ConvertToUnixSlashes(std::string& path)
     pathCString = path.c_str();
     if(pathCString[0] == '~' && (pathCString[1] == '/' || pathCString[1] == '\0'))
       {
-      const char* homeEnv = SystemTools::GetEnv("HOME");
-      if (homeEnv)
+      std::string homeEnv;
+      if (SystemTools::GetEnv("HOME", homeEnv))
         {
         path.replace(0,1,homeEnv);
         }
@@ -4061,16 +4099,9 @@ void SystemTools::SplitPath(const std::string& p,
     if(root.size() == 1)
       {
 #if defined(_WIN32) && !defined(__CYGWIN__)
-      if(const char* userp = getenv("USERPROFILE"))
-        {
-        homedir = userp;
-        }
-      else
+      if (!SystemTools::GetEnv("USERPROFILE", homedir))
 #endif
-      if(const char* h = getenv("HOME"))
-        {
-        homedir = h;
-        }
+      SystemTools::GetEnv("HOME", homedir);
       }
 #ifdef HAVE_GETPWNAM
     else if(passwd* pw = getpwnam(root.c_str()+1))
@@ -4811,7 +4842,7 @@ int SystemTools::GetTerminalWidth()
   int width = -1;
 #ifdef HAVE_TTY_INFO
   struct winsize ws;
-  char *columns; /* Unix98 environment variable */
+  std::string columns; /* Unix98 environment variable */
   if(ioctl(1, TIOCGWINSZ, &ws) != -1 && ws.ws_col>0 && ws.ws_row>0)
     {
     width = ws.ws_col;
@@ -4820,12 +4851,11 @@ int SystemTools::GetTerminalWidth()
     {
     width = -1;
     }
-  columns = getenv("COLUMNS");
-  if(columns && *columns)
+  if(SystemTools::GetEnv("COLUMNS", columns))
     {
     long t;
     char *endptr;
-    t = strtol(columns, &endptr, 0);
+    t = strtol(columns.c_str(), &endptr, 0);
     if(endptr && !*endptr && (t>0) && (t<1000))
       {
       width = static_cast<int>(t);
@@ -5435,7 +5465,8 @@ void SystemTools::ClassInitialize()
 
   // If the current working directory is a logical path then keep the
   // logical name.
-  if(const char* pwd = getenv("PWD"))
+  std::string pwd_str;
+  if(SystemTools::GetEnv("PWD", pwd_str))
     {
     char buf[2048];
     if(const char* cwd = Getcwd(buf, 2048))
@@ -5447,10 +5478,9 @@ void SystemTools::ClassInitialize()
       std::string pwd_changed;
 
       // Test progressively shorter logical-to-physical mappings.
-      std::string pwd_str = pwd;
       std::string cwd_str = cwd;
       std::string pwd_path;
-      Realpath(pwd, pwd_path);
+      Realpath(pwd_str.c_str(), pwd_path);
       while(cwd_str == pwd_path && cwd_str != pwd_str)
         {
         // The current pair of paths is a working logical mapping.
@@ -5505,8 +5535,8 @@ static int SystemToolsDebugReport(int, char* message, int*)
 
 void SystemTools::EnableMSVCDebugHook()
 {
-  if (getenv("DART_TEST_FROM_DART") ||
-      getenv("DASHBOARD_TEST_FROM_CTEST"))
+  if (SystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      SystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST"))
     {
     _CrtSetReportHook(SystemToolsDebugReport);
     }
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..643f0ca 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -839,10 +839,10 @@ public:
   /**
    * Read an environment variable
    */
-  static const char* GetEnv(const char* key);
-  static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
+  static bool HasEnv(const char* key);
+  static bool HasEnv(const std::string& key);
 
   /** Put a string into the environment
       of the form var=value */
diff --git a/Source/kwsys/testSystemTools.cxx b/Source/kwsys/testSystemTools.cxx
index 4d97688..0fcc561 100644
--- a/Source/kwsys/testSystemTools.cxx
+++ b/Source/kwsys/testSystemTools.cxx
@@ -848,9 +848,9 @@ static bool CheckPutEnv(const std::string& env, const char* name, const char* va
                     << "\") failed!" << std::endl;
     return false;
     }
-  const char* v = kwsys::SystemTools::GetEnv(name);
-  v = v? v : "(null)";
-  if(strcmp(v, value) != 0)
+  std::string v = "(null)";
+  kwsys::SystemTools::GetEnv(name, v);
+  if(strcmp(v.c_str(), value) != 0)
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not \"" << value << "\"!" << std::endl;
@@ -867,7 +867,8 @@ static bool CheckUnPutEnv(const char* env, const char* name)
                     << std::endl;
     return false;
     }
-  if(const char* v = kwsys::SystemTools::GetEnv(name))
+  std::string v;
+  if(kwsys::SystemTools::GetEnv(name, v))
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not (null)!" << std::endl;
-- 
2.9.0


From mikedld at mikedld.com  Sun Jul  3 06:04:30 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Sun, 3 Jul 2016 13:04:30 +0300
Subject: [cmake-developers] [PATCH v2] Improve encoding handling on
 Windows
In-Reply-To: <20160703002941.4330-1-davispuh@gmail.com>
References: <20160703002941.4330-1-davispuh@gmail.com>
Message-ID: <112ce1ba-9c54-238e-3f1b-93a616af9a80@mikedld.com>

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 people to use one or another stream based on
current OS.

Not sure what currently accepted CMake coding style dictates, but
several variables could be made const (e.g. `envVarSet` in
`cmExtraEclipseCDT4Generator::AddEnvVar`).

Apart from notes above and a few indentation issues which may be fixed
during merge, below are some more observations.

On 07/03/2016 03:29 AM, D?vis Mos?ns wrote:
> --- a/Source/CTest/cmCTestCurl.cxx
> +++ b/Source/CTest/cmCTestCurl.cxx
> @@ -238,12 +238,11 @@ void cmCTestCurl::SetProxyType()
>          this->HTTPProxyType = CURLPROXY_SOCKS5;
>        }
>      }
> -    if (cmSystemTools::GetEnv("HTTP_PROXY_USER")) {
> -      this->HTTPProxyAuth = cmSystemTools::GetEnv("HTTP_PROXY_USER");
> -    }
> -    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD")) {
> +    cmSystemTools::GetEnv("HTTP_PROXY_USER", this->HTTPProxyAuth);
> +    std::string passwd;
> +    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD", passwd)) {
>        this->HTTPProxyAuth += ":";
> -      this->HTTPProxyAuth += cmSystemTools::GetEnv("HTTP_PROXY_PASSWD");
> +      this->HTTPProxyAuth += passwd;
>      }
>    }
>  }
I guess the logic was a bit flawed to begin with. The function doesn't
look reenterable so I would presume that it's being called with empty
`this->HTTP*` variables. Adding asserts wouldn't hurt (though not in
terms of this patch).

> --- a/Source/cmBuildCommand.cxx
> +++ b/Source/cmBuildCommand.cxx
> @@ -109,10 +109,7 @@ bool cmBuildCommand::TwoArgsSignature(std::vector<std::string> const& args)
>    const char* cacheValue = this->Makefile->GetDefinition(define);
>  
>    std::string configType = "Release";
> -  const char* cfg = getenv("CMAKE_CONFIG_TYPE");
> -  if (cfg && *cfg) {
> -    configType = cfg;
> -  }
> +  cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configType);
>  
>    std::string makecommand =
>      this->Makefile->GetGlobalGenerator()->GenerateCMakeBuildCommand(
Here you have a slight change in logic. Assuming environment variable
could be present but empty, I would rewrite this piece to:

std::string configType;
if (!cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configType) ||
configType.empty())
  configType = "Release";

You already have this code pattern some place else.

> --- a/Source/cmCLocaleEnvironmentScope.cxx
> +++ b/Source/cmCLocaleEnvironmentScope.cxx
> @@ -31,8 +31,8 @@ cmCLocaleEnvironmentScope::cmCLocaleEnvironmentScope()
>  
>  std::string cmCLocaleEnvironmentScope::GetEnv(std::string const& key)
>  {
> -  const char* value = cmSystemTools::GetEnv(key);
> -  return value ? value : std::string();
> +  std::string value;
> +  return cmSystemTools::GetEnv(key, value) ? value : std::string();
>  }
>  
>  void cmCLocaleEnvironmentScope::SetEnv(std::string const& key,
Assuming there's NRVO in place, ignoring return value of
`cmSystemTools::GetEnv` call might be a better choice; if the call
fails, `value` stays empty, so you could return `value` regardless.

> --- a/Source/cmSetCommand.cxx
> +++ b/Source/cmSetCommand.cxx
> @@ -31,7 +31,11 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
>      putEnvArg += "=";
>  
>      // what is the current value if any
> -    const char* currValue = getenv(varName);
> +    std::string scurrValue;
> +    const char* currValue = 0;
> +    if (cmSystemTools::GetEnv(varName, scurrValue)) {
> +      currValue = scurrValue.c_str();
> +    }
>      delete[] varName;
>  
>      // will it be set to something, then set it
Could be changed to std::string + bool instead. Two pointer checks which
follow will then use the bool value, and `strcmp()` call will be
replaced with plain `currValue != argv[1]`.

> --- a/Source/cmake.cxx
> +++ b/Source/cmake.cxx
> @@ -1708,8 +1702,8 @@ int cmake::CheckBuildSystem()
>    // the make system's VERBOSE environment variable to enable verbose
>    // output. This can be skipped by setting CMAKE_NO_VERBOSE (which is set
>    // by the Eclipse and KDevelop generators).
> -  bool verbose = ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
> -                  (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
> +  bool verbose = ((cmSystemTools::HasEnv("VERBOSE")) &&
> +                  (!cmSystemTools::HasEnv("CMAKE_NO_VERBOSE")));
>  
>    // This method will check the integrity of the build system if the
>    // option was given on the command line.  It reads the given file to
Extra parentheses weren't exactly needed before, and are certainly
useless now ;)

> --- a/Source/cmcmd.cxx
> +++ b/Source/cmcmd.cxx
> @@ -701,8 +701,8 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
>        // verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
>        // (which is set by the Eclipse and KDevelop generators).
>        bool verbose =
> -        ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
> -         (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
> +        ((cmSystemTools::HasEnv("VERBOSE")) &&
> +         (!cmSystemTools::HasEnv("CMAKE_NO_VERBOSE")));
>  
>        // Create a cmake object instance to process dependencies.
>        cmake cm;
Same as above. In fact, this is a copy-paste code, someone should add a
helper I suppose.

> --- a/Source/kwsys/SystemTools.cxx
> +++ b/Source/kwsys/SystemTools.cxx
> @@ -456,22 +454,45 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
>      }
>  }
>  
> -const char* SystemTools::GetEnv(const char* key)
> +bool SystemTools::GetEnv(const char* key, std::string& result)
>  {
> -  return getenv(key);
> +#if defined(_WIN32)
> +  std::wstring wkey = Encoding::ToWide(key);
> +  wchar_t* wv = _wgetenv(wkey.c_str());
> +  if (wv) {
> +    result = Encoding::ToNarrow(wv);
> +    return true;
> +  }
> +  return false;
> +#else
> +  const char* v = getenv(key);
> +  if(v)
> +    {
> +    result = v;
> +    return true;
> +    }
> +  else
> +    {
> +    return false;
> +    }
> +#endif
>  }
Short-circuiting would be nice, no point in code like `if (...) { ...
return A; } else { ... return B; }`.

> ...
>
> -bool SystemTools::GetEnv(const char* key, std::string& result)
> +bool SystemTools::HasEnv(const char* key)
>  {
> +#if defined(_WIN32)
> +  std::wstring wkey = Encoding::ToWide(key);
> +  wchar_t* v = _wgetenv(wkey.c_str());
> +#else
>    const char* v = getenv(key);
> +#endif
>    if(v)
>      {
> -    result = v;
>      return true;
>      }
>    else
Looks like simple `return v != CM_NULLPTR;` to me.

> ...
>
> @@ -4820,12 +4851,11 @@ int SystemTools::GetTerminalWidth()
>      {
>      width = -1;
>      }
> -  columns = getenv("COLUMNS");
> -  if(columns && *columns)
> +  if(SystemTools::GetEnv("COLUMNS", columns))
>      {
>      long t;
>      char *endptr;
Yet another small change in behavior. Needs ` && !columns.empty()`
added. Although I see why you may have omitted it intentionally...
Granted, saving one call to strtol may not be worth it.

> --- a/Source/kwsys/SystemTools.hxx.in
> +++ b/Source/kwsys/SystemTools.hxx.in
> @@ -839,10 +839,10 @@ public:
>    /**
>     * Read an environment variable
>     */
> -  static const char* GetEnv(const char* key);
> -  static const char* GetEnv(const std::string& key);
>    static bool GetEnv(const char* key, std::string& result);
>    static bool GetEnv(const std::string& key, std::string& result);
> +  static bool HasEnv(const char* key);
> +  static bool HasEnv(const std::string& key);
>  
>    /** Put a string into the environment
>        of the form var=value */
As other people seem to be concerned with API compatibility (in kwsys in
particular), it might be better to leave existing "const char*
SystemTools::GetEnv(const char* key)" and "const char*
SystemTools::GetEnv(const std::string& key)" signatures around but mark
them with deprecation pragma to discourage their use?

> --- a/Source/kwsys/testSystemTools.cxx
> +++ b/Source/kwsys/testSystemTools.cxx
> @@ -848,9 +848,9 @@ static bool CheckPutEnv(const std::string& env, const char* name, const char* va
>                      << "\") failed!" << std::endl;
>      return false;
>      }
> -  const char* v = kwsys::SystemTools::GetEnv(name);
> -  v = v? v : "(null)";
> -  if(strcmp(v, value) != 0)
> +  std::string v = "(null)";
> +  kwsys::SystemTools::GetEnv(name, v);
> +  if(strcmp(v.c_str(), value) != 0)
>      {
>      std::cerr << "GetEnv(\"" << name << "\") returned \""
>                      << v << "\", not \"" << value << "\"!" << std::endl;
As you're using std::string now, `if (v != value)` might be a better
(cleaner) alternative.

Regards,
Mike

From steveire at gmail.com  Sun Jul  3 06:27:22 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 03 Jul 2016 12:27:22 +0200
Subject: [cmake-developers] cmake -E capabilities
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io> <5776691F.5020907@kitware.com>
Message-ID: <nlapaa$s3g$1@ger.gmane.org>

Brad King wrote:

> On 07/01/2016 05:11 AM, Tobias Hunger wrote:
>>> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
>> I do not see why this information is need to set up a cmake project. I
>> need two directories and a generator. Do I need to know what the
>> generator produces at that point?
> 
> If we don't foresee a use case for it we don't need to add it now.  The
> example given in the issue was just a quick demo IIUC and not intended to
> be authoritative result of deep design thought.

I can confirm this.

>> If "-A" is the way to go, then I would like to try my hand at adding
>> a method to retrieve all valid platforms for a generator. CMake has
>> a lot of code to find those names (or hardcodes known names), so why
>> not pass it on to the user?
> 
> If it is reasonably straightforward to do then go for it.  That would
> be nice to offer.

Does Visual Studio have a drop-down menu or similar for this? If yes, then 
such a list would be good to have I think.

Thanks,

Steve.



From steveire at gmail.com  Sun Jul  3 06:33:55 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 03 Jul 2016 12:33:55 +0200
Subject: [cmake-developers] cmake -E capabilities
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io>
Message-ID: <nlapmk$239$1@ger.gmane.org>

Tobias Hunger wrote:

> Either we should have multiConfig return a list of configuration names
> that will be generated or I do not see any need to have the information in
> the first place.

I think when using qmake with QtCreator, the user can choose the 
configuration at build time by selecting it from the left-side menu.

Such a feature would also work with cmake projects if the user chooses to 
use the XCode generator on mac or VS generator on Windows (or if someday we 
have a multi-config Ninja generator or so).

However, I don't think that is an immediate goal, and that information can 
be added later easily if a client does need it.

Thanks,

Steve.



From steveire at gmail.com  Sun Jul  3 07:30:26 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 03 Jul 2016 13:30:26 +0200
Subject: [cmake-developers] cmake -E capabilities
References: <1467294716.811.298.camel@qt.io>
Message-ID: <nlat0i$jfv$1@ger.gmane.org>

Tobias Hunger wrote:

> Hello CMake Developers!
> 
> As laid out in the last mail thread about daemon-mode in CMake (for your
> reference:
> http://public.kitware.com/pipermail/cmake-developers/2016-June/028777
> .html ), Stephen and me agreed that we needed a way for IDEs to figure out
> which generators are available to cmake and more static information built
> into CMake.

Here's a gmane link to the thread for reference:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16782

> There is actually a bug report about the need for this feature here:
> https://gitlab.kitware.com/cmake/cmake/issues/15462
> 
> This is my attempt to solve the issue:
> https://github.com/hunger/CMake/commits/cmake-capabilities

Thanks for working on this.

> The output looks like this:
>> cmake -E capabilities --pretty-print
> {
> "generators" : [
> {
> "extraGenerators" : [],

Interesting. I didn't realize the "Watcom WMake" generator does not work 
with 'extra' generators.

> "KDevelop3",

<off topic> This generator should probably be removed/hidden by now. It has 
confused users of more-recent KDevelop versions.

> What do you think? What else should we report here?

It looks like a good start. The intention of the output is to satisfy needs 
that consumers like you have, and I guess it does have what you need.

> Compared to the bug report mentioned above the fields "multiconfig" and
> "recursive" are missing. I could not figure out how to get that
> information:-/

When I made the example in the issue tracker, 'recursive' meant 'you can cd 
to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was 
possible to do that when using the Makefiles generator, but not the Ninja 
generator. 

I think that capability has since been added for the Ninja generator, but I 
don't know if it is possible with the Xcode and VS generators.

Would that be a useful thing to expose here in your view?

> I would also welcome some code review on the patch. 

1) For consistency you should change 

 GetRegisteredGenerators

to 

 this->GetRegisteredGenerators

whether that is a preferred style is orthogonal to the fact that it's 
consistently used in cmake code.

2) CMake has to build with toolchains which do not provide 
std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing 
code which uses either std::unordered_map or std::unordered_map. (Yes there 
is room for improvement there, but such improvement is orthogonal to your 
branch).

3) Similarly, CMake has to build with compilers which do not support 
cxx_range_for or cxx_auto_type. For the cmServer implementation that may or 
may not be the case, but within the cmake class, that's the way it is.

4) It seems that the 

 this->Generators

member of the cmake class has the names of all generators (without 'extra' 
generators). It seems unfortunate to not use that container and instead 
parse the names out of the names from the GetRegisteredGenerators call by 
splitting on the ' - '. It leads to hard coded magic expressions like 
'separator + 3', so it should be avoided if possible.

Is there another way of determining the extra generators supported by a 
given generator and avoiding parsing a string which we just generated? Can 

  const std::vector<std::string>& supportedGlobalGenerators =
    extraGenerator->GetSupportedGlobalGenerators();

be used somehow? Can you first loop over this->Generators to get the 
'normal' generators, then loop over the extra generators, call that method 
to match things up and output the result?

Or would it make sense to refactor the container members in the cmake class 
themselves to make this information more easily available for this use-case?

5) You use the term 'appendix' for the version, but 'suffix' is the more-
commonly used name for that concept.



Thanks,

Steve.



From davispuh at gmail.com  Sun Jul  3 09:22:20 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Sun, 3 Jul 2016 16:22:20 +0300
Subject: [cmake-developers] [PATCH v2] Improve encoding handling on
	Windows
In-Reply-To: <112ce1ba-9c54-238e-3f1b-93a616af9a80@mikedld.com>
References: <20160703002941.4330-1-davispuh@gmail.com>
 <112ce1ba-9c54-238e-3f1b-93a616af9a80@mikedld.com>
Message-ID: <CAOE4rSzPKnUeWbwxDnTkXU+rxQH_s_4OCP0pfKY9z9JiBrJA=g@mail.gmail.com>

2016-07-03 13:04 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:

> 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 people to use one or another stream based on
> current OS.
>
> Not sure what currently accepted CMake coding style dictates, but
> several variables could be made const (e.g. `envVarSet` in
> `cmExtraEclipseCDT4Generator::AddEnvVar`).
>
> Apart from notes above and a few indentation issues which may be fixed
> during merge, below are some more observations.
>
>
Huge thanks for review! Will fix mentioned issues in next version of patch.
Also I'll implement this solution with std::streambuf as it's much better
way
and it's actually not that much work I thought it would be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160703/aca5d32d/attachment.html>

From Tobias.Hunger at qt.io  Mon Jul  4 04:18:11 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Mon, 4 Jul 2016 08:18:11 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <nlapmk$239$1@ger.gmane.org>
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io> <nlapmk$239$1@ger.gmane.org>
Message-ID: <1467620290.846.9.camel@qt.io>

On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote:
> Tobias Hunger wrote:
> 
> > Either we should have multiConfig return a list of configuration names
> > that will be generated or I do not see any need to have the information in
> > the first place.
> 
> I think when using qmake with QtCreator, the user can choose the?
> configuration at build time by selecting it from the left-side menu.

I do not understand what you are getting at.

That widget already works for cmake projects in Qt Creator: It switches between
different build directories with different configurations.

> Such a feature would also work with cmake projects if the user chooses to?
> use the XCode generator on mac or VS generator on Windows (or if someday we?
> have a multi-config Ninja generator or so).

How is a multi-config ninja generator better than just having to build
directories next to each other, each with one configuration? You might save a
bit of disk space (probably not a lot). Will you save a significant amount of
processing time?

The one benefit I can think of is switching between configurations will probably
be a lot faster. But that is nothing that is done so often that it warrants
optimizing for IMHO.

> However, I don't think that is an immediate goal, and that information can?
> be added later easily if a client does need it.

I still think the information "this generator can handle multiple configurations
in one build directory" is useless to all clients I can think of.

Either the clients do not care or they need to know which configurations those
are going to be.

Best Regards,
Tobias

-- Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From steveire at gmail.com  Mon Jul  4 19:48:33 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 05 Jul 2016 01:48:33 +0200
Subject: [cmake-developers] cmake -E capabilities
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io> <nlapmk$239$1@ger.gmane.org>
 <1467620290.846.9.camel@qt.io>
Message-ID: <nleskh$qcc$1@ger.gmane.org>

Tobias Hunger wrote:

> On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote:
>> Tobias Hunger wrote:
>> 
>> > Either we should have multiConfig return a list of configuration names
>> > that will be generated or I do not see any need to have the information
>> > in the first place.
>> 
>> I think when using qmake with QtCreator, the user can choose the
>> configuration at build time by selecting it from the left-side menu.
> 
> I do not understand what you are getting at.
> 
> That widget already works for cmake projects in Qt Creator: It switches
> between different build directories with different configurations.

Ok. I'm not sure that worked when I tried it years ago :).

>> Such a feature would also work with cmake projects if the user chooses to
>> use the XCode generator on mac or VS generator on Windows (or if someday
>> we have a multi-config Ninja generator or so).
> 
> How is a multi-config ninja generator better than just having to build
> directories next to each other, each with one configuration? You might
> save a bit of disk space (probably not a lot). Will you save a significant
> amount of processing time?
> 
> The one benefit I can think of is switching between configurations will
> probably be a lot faster. But that is nothing that is done so often that
> it warrants optimizing for IMHO.

What I have in mind is not optimization. As you say, if this is not needed 
at this point for IDE integration, then we can drop the idea.

> Either the clients do not care or they need to know which configurations
> those are going to be.

This can be retrieved by reading the STRINGS property of the 
CMAKE_BUILD_TYPE cache variable.

Thanks,

Steve.



From ruslan_baratov at yahoo.com  Tue Jul  5 06:29:16 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 13:29:16 +0300
Subject: [cmake-developers] [patch] Document -H and -B
In-Reply-To: <577668D9.5070104@kitware.com>
References: <c391e994-cd36-a61c-05ee-7b86fbc28a99@yahoo.com>
 <5775738F.8000709@kitware.com>
 <a9dcf1b6-5434-cc83-8eec-f51736a6ff3f@yahoo.com>
 <57757E7B.9050904@kitware.com>
 <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com>
 <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com>
 <CALSpCT0n3jUUSuYD7SneoBT0suP5YB2CYUNsyP1=aLsLb013ZQ@mail.gmail.com>
 <a8a2d867-0fc1-1f22-b527-3982961ec370@yahoo.com>
 <CALSpCT115zzJgKz4=dS_yPkzf=xvCp10BTOfaj4osUReLbcoEQ@mail.gmail.com>
 <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com>
 <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
 <577668D9.5070104@kitware.com>
Message-ID: <cf0cdc31-0d7f-a180-b5de-2f306a185d45@yahoo.com>

On 01-Jul-16 15:58, Brad King wrote:
>
> * Allow the form `-H <value> -B <value>` with the new names.
>
I don't see the point of introducing new options. Developers will still 
use -H/-B because it's backward compatible, well known and will work 
100% because of internal CMake testing. That said if you want to improve 
the current behavior of -H/-B (like confusing with --help/no spaces 
between -H and <path-to-source-tree>) I can take a look. Otherwise I'm 
not interested (usually it means that the improvement will be abandoned).

Ruslo

From ruslan_baratov at yahoo.com  Tue Jul  5 09:26:54 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 16:26:54 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
Message-ID: <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>

Got another idea. We can use default name like 'archive.tar'. Seems that 
internal type of archive determined automatically and doesn't depends on 
the filename. I've tried one example for each extension: 7z, tar.bz2, 
tar.gz, tar.xz, tbz2, tgz, txz, zip and it just works. Patch attached.

Ruslo

On 01-Jul-16 15:01, Ruslan Baratov via cmake-developers wrote:
> Hi,
>
> With attached patch it's possible to extract name from URLs like 
> 'https://.../archive.tar.gz?a=x&b=y'.
>
> Ruslo 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-default-filename-if-extracting-from-URL-failed.patch
Type: text/x-patch
Size: 1213 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160705/a8f68158/attachment.bin>

From ben.boeckel at kitware.com  Tue Jul  5 09:49:54 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 5 Jul 2016 09:49:54 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
Message-ID: <20160705134954.GB7724@megas.kitware.com>

On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers wrote:
> +          # Do not put warning message here. If everything works OK it will
> +          # only distract. If unpack will fail the standard name can be found in logs.
> +          # (see _ep_write_extractfile_script function)
> +          set(fname "archive.tar")

Is this going to cause multiple tarball downloads to overwrite each
other in the download cache directory?

--Ben

From ruslan_baratov at yahoo.com  Tue Jul  5 11:43:25 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 18:43:25 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20160705134954.GB7724@megas.kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
Message-ID: <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>

By default not, goes to <project-name>-prefix/src/archive.tar .

On 05-Jul-16 16:49, Ben Boeckel wrote:
> On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers wrote:
>> +          # Do not put warning message here. If everything works OK it will
>> +          # only distract. If unpack will fail the standard name can be found in logs.
>> +          # (see _ep_write_extractfile_script function)
>> +          set(fname "archive.tar")
> Is this going to cause multiple tarball downloads to overwrite each
> other in the download cache directory?
>
> --Ben



From ben.boeckel at kitware.com  Tue Jul  5 11:50:57 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 5 Jul 2016 11:50:57 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
Message-ID: <20160705155057.GB11277@megas.kitware.com>

On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:
> By default not, goes to <project-name>-prefix/src/archive.tar .

Right, but if a download directory is set, this won't work. Can the
project name at least be added to the name?

Though I'm partial to keeping the extension still; if I need to add a
patch to a project, it'd be nice if the extension weren't a lie when I
go to extract the tarball.

--Ben

From ruslan_baratov at yahoo.com  Tue Jul  5 12:49:46 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 19:49:46 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20160705155057.GB11277@megas.kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
Message-ID: <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>

On 05-Jul-16 18:50, Ben Boeckel wrote:
> On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:
>> By default not, goes to <project-name>-prefix/src/archive.tar .
> Right, but if a download directory is set, this won't work. Can the
> project name at least be added to the name?
If user are forcing directory then it is user's responsibility I think. 
For example GitHub releases goes without name of the project so both:

* https://github.com/ruslo/polly/archive/v0.10.1.tar.gz
* https://github.com/ruslo/hunter/archive/v0.10.1.tar.gz

will be downloaded to v0.10.1.tar.gz - this filename extracted from URL 
by CMake. In general patch made in a code branch where was FATAL_ERROR 
before, so it doesn't affect backward compatibility.

>
> Though I'm partial to keeping the extension still; if I need to add a
> patch to a project, it'd be nice if the extension weren't a lie when I
> go to extract the tarball.
Archive can be unpacked by "cmake -E tar xf" which detect type 
automatically as far as I understand. At least this one used internally 
by ExternalProject (see the testing I've made before).

Also note that in fact name of the file extracted from URL can differ 
from real:
|
 > curl --head 
https://gitlab.com/gitlab-org/gitlab-ce/repository/archive.tar.gz\?ref\=v8.9.3 
| grep file
Content-Disposition: attachment; 
filename="gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz"|

So even if it seems that archive name is `|archive.tar.gz` it should be 
downloaded to 
`||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
I think it's easily can be file with another extension.|

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160705/5dfffb6d/attachment.html>

From brad.king at kitware.com  Tue Jul  5 13:04:03 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 13:04:03 -0400
Subject: [cmake-developers] [PATCH v2] Improve encoding handling on
 Windows
In-Reply-To: <CAOE4rSzPKnUeWbwxDnTkXU+rxQH_s_4OCP0pfKY9z9JiBrJA=g@mail.gmail.com>
References: <20160703002941.4330-1-davispuh@gmail.com>
 <112ce1ba-9c54-238e-3f1b-93a616af9a80@mikedld.com>
 <CAOE4rSzPKnUeWbwxDnTkXU+rxQH_s_4OCP0pfKY9z9JiBrJA=g@mail.gmail.com>
Message-ID: <577BE883.8090404@kitware.com>

On 07/03/2016 09:22 AM, D?vis Mos?ns wrote:
> Huge thanks for review! Will fix mentioned issues in next version of patch.
> Also I'll implement this solution with std::streambuf as it's much better way
> and it's actually not that much work I thought it would be.

Yes, thanks Mike!

D?vis, in the next round please split out refactoring changes like
converting clients to the alternative GetEnv signature into preceding
commits.  That will simplify review and allow many hunks to be
integrated even if other changes need more revisions.

Thanks,
-Brad


From ben.boeckel at kitware.com  Tue Jul  5 13:31:53 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 5 Jul 2016 13:31:53 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
 <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
Message-ID: <20160705173153.GB15264@megas.kitware.com>

On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:
> Archive can be unpacked by "cmake -E tar xf" which detect type 
> automatically as far as I understand. At least this one used internally 
> by ExternalProject (see the testing I've made before).

CMake is not my go-to tool for extracting files though (and similarly
for others I imagine), so running `tar xf archive.tar` and getting an
error because it is actually a .tar.gz (or even a .zip) file is not
nice.

> So even if it seems that archive name is `|archive.tar.gz` it should be 
> downloaded to 
> `||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
> I think it's easily can be file with another extension.|

Here's another idea: add an `OUTPUT_FILE <var>` keyword argument to
`file(DOWNLOAD)` to get the actual filename after content disposition
resolution (probably similar for 30x rewrites). This would also be
useful for things other than ExternalProject.

--Ben

From brad.king at kitware.com  Tue Jul  5 13:46:06 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 13:46:06 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20160705173153.GB15264@megas.kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
 <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
 <20160705173153.GB15264@megas.kitware.com>
Message-ID: <577BF25E.10909@kitware.com>

On 07/05/2016 01:31 PM, Ben Boeckel wrote:
> Here's another idea: add an `OUTPUT_FILE <var>` keyword argument to
> `file(DOWNLOAD)` to get the actual filename after content disposition
> resolution (probably similar for 30x rewrites). This would also be
> useful for things other than ExternalProject.

This may be a reasonable idea for the future but we are getting
way off from the original patch here.

I will likely commit something from this thread when I get a chance
to review it.

-Brad


From ruslan_baratov at yahoo.com  Tue Jul  5 14:01:36 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 21:01:36 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20160705173153.GB15264@megas.kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
 <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
 <20160705173153.GB15264@megas.kitware.com>
Message-ID: <20bcb8ae-5d1a-00ec-4f64-37e1314c7225@yahoo.com>

On 05-Jul-16 20:31, Ben Boeckel wrote:
> On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:
>> Archive can be unpacked by "cmake -E tar xf" which detect type
>> automatically as far as I understand. At least this one used internally
>> by ExternalProject (see the testing I've made before).
> CMake is not my go-to tool for extracting files though (and similarly
> for others I imagine), so running `tar xf archive.tar` and getting an
> error because it is actually a .tar.gz (or even a .zip) file is not
> nice.
Well it's never too late to learn something new. Also `tar` is not 
widely used on Windows so to write nice code you should convert it to 
`cmake -E tar`. That the whole point of `cmake -E` feature.
I don't see the problem here, it was used internally, unpack archive for 
you and you can do what you want with **unpacked** sources. Anyway you 
can always force the name with |DOWNLOAD_NAME.|

>> So even if it seems that archive name is `|archive.tar.gz` it should be
>> downloaded to
>> `||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So
>> I think it's easily can be file with another extension.|
> Here's another idea: add an `OUTPUT_FILE <var>` keyword argument to
> `file(DOWNLOAD)` to get the actual filename after content disposition
> resolution (probably similar for 30x rewrites). This would also be
> useful for things other than ExternalProject.
>
> --Ben
Good idea, I'll be happy to see this feature in future CMake releases.

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160705/fb228a4a/attachment.html>

From brad.king at kitware.com  Tue Jul  5 14:13:59 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 14:13:59 -0400
Subject: [cmake-developers] Green Hills MULTI Generator Recommendations
In-Reply-To: <CAAAjsBoLPf9_ajf=td1_XwEX4mVUVfo2Q-pdascyotMyjcMxJQ@mail.gmail.com>
References: <CAAAjsBoLPf9_ajf=td1_XwEX4mVUVfo2Q-pdascyotMyjcMxJQ@mail.gmail.com>
Message-ID: <577BF8E7.9080105@kitware.com>

On 07/02/2016 02:21 PM, Chris Bux wrote:
> I am interested in using CMake with Green Hills MULTI.

Adding Geoffrey Viola to Cc who implemented the current GHS support.

> Should the MULTI generator provide a list of known compiler names
> by architecture, or should we rely on users to set the appropriate
> CMAKE_<LANG>_COMPILER variables in the toolchain file?

The latter for now.

> If the generator should provide a list of known compiler names,
> would CMake's -A option be the appropriate way to specify the target
> processor's platform?

No, the -A option is for when the underlying build system (e.g. VS IDE)
has declarative options to specify things like that.

> 2. Is there a way in a toolchain file or on the command line to specify
> the directory where CMake should look for the compiler executables?

The find_program command is used for some generators.  I don't recall
if GHS does its own thing or not.  One could add it to ENV{PATH} or
see the documentation of the find_program command for how it searches.

> 3. Is there a way to specify the make executable full path in the toolchain file?

Try making it a cache entry:

 set(CMAKE_MAKE_PROGRAM /path/to/gbuild CACHE FILEPATH "path to gbuild")

Note that toolchain files are meant to be produced locally and
hard-coded for a local machine, so such content is appropriate.

Thanks,
-Brad


From ben.boeckel at kitware.com  Tue Jul  5 14:21:42 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 5 Jul 2016 14:21:42 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <20bcb8ae-5d1a-00ec-4f64-37e1314c7225@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
 <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
 <20160705173153.GB15264@megas.kitware.com>
 <20bcb8ae-5d1a-00ec-4f64-37e1314c7225@yahoo.com>
Message-ID: <20160705182142.GA30320@megas.kitware.com>

On Tue, Jul 05, 2016 at 21:01:36 +0300, Ruslan Baratov wrote:
> Well it's never too late to learn something new. Also `tar` is not 
> widely used on Windows so to write nice code you should convert it to 
> `cmake -E tar`. That the whole point of `cmake -E` feature.
> I don't see the problem here, it was used internally, unpack archive for 
> you and you can do what you want with **unpacked** sources. Anyway you 
> can always force the name with |DOWNLOAD_NAME.|

I'm more considering the case of using the files as they exist on the
disk for other purposes, not necessarily through code (which probably
should be using `cmake -E tar`). For example, I will do:

  - tar xf $tarball.tar.gz
  - cp -a $tarball $tarball.to-patch
  - $edit .to-patch
  - diff -U5 -r $tarball $tarball.to-patch

to create patches for ExternalProject tarballs we use.

--Ben

From brad.king at kitware.com  Tue Jul  5 15:03:47 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 15:03:47 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <5776C60F.8070901@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com>
Message-ID: <577C0493.7060303@kitware.com>

On 07/01/2016 03:35 PM, Brad King wrote:
> I don't think we should duplicate the
> 
>   "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"
> 
> expression.  The stripping of ?.* can be done earlier, or done as
> part of the main match.

Please try this commit:

 ExternalProject: Match filenames in URLs with query strings and anchors
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57c337e2

Thanks,
-Brad


From ben.boeckel at kitware.com  Tue Jul  5 15:19:16 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 5 Jul 2016 15:19:16 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <577BF25E.10909@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <6f527420-6433-f165-a815-3a348a27d9d8@yahoo.com>
 <20160705134954.GB7724@megas.kitware.com>
 <aba18be9-ab7b-eaa0-e797-0730b874b702@yahoo.com>
 <20160705155057.GB11277@megas.kitware.com>
 <270f826b-c898-87cc-00bc-2887b618fb10@yahoo.com>
 <20160705173153.GB15264@megas.kitware.com>
 <577BF25E.10909@kitware.com>
Message-ID: <20160705191916.GA20133@megas.kitware.com>

On Tue, Jul 05, 2016 at 13:46:06 -0400, Brad King wrote:
> On 07/05/2016 01:31 PM, Ben Boeckel wrote:
> > Here's another idea: add an `OUTPUT_FILE <var>` keyword argument to
> > `file(DOWNLOAD)` to get the actual filename after content disposition
> > resolution (probably similar for 30x rewrites). This would also be
> > useful for things other than ExternalProject.
> 
> This may be a reasonable idea for the future but we are getting
> way off from the original patch here.

    https://gitlab.kitware.com/cmake/cmake/issues/16187

--Ben

From konstantin at podsvirov.pro  Tue Jul  5 15:39:19 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 05 Jul 2016 22:39:19 +0300
Subject: [cmake-developers] Fwd: CMake | CPackIFW: Using
	cpack_append_list_variable_set_command (!27)
In-Reply-To: <518031467747445@web11o.yandex.ru>
Message-ID: <520951467747559@web11o.yandex.ru>

-------- sending message  --------
05.07.2016, 22:37, "Konstantin Podsvirov" <konstantin at podsvirov.pro>:

Thanks, Brad!

I've been waiting for your answer :-)

05.07.2016, 22:30, "Brad King" <gitlab at gitlab.kitware.com>:
> ?Thanks. I've merged this to next for testing.

I found a small bug in CPackIFW. The patch is attached.

I read the wrong documentation for QtIFW (https://bugreports.qt.io/browse/QTIFW-873) and made the wrong generation.
I conducted a series of tests and now everything should work correctly.

I have a household question:
Changes are best to send to a mailing list or use your gitlab?
-------- sending message  --------

Regards,
Konstantin Podsvirov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-CPackIFW-Fixed-attributes-for-repository-replace.patch
Type: text/x-diff
Size: 988 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160705/553dbd5a/attachment.patch>

From brad.king at kitware.com  Tue Jul  5 15:58:04 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 15:58:04 -0400
Subject: [cmake-developers] Fix bug in CPack IFW Promoting Updates
	repository replacement
In-Reply-To: <520951467747559@web11o.yandex.ru>
References: <520951467747559@web11o.yandex.ru>
Message-ID: <577C114C.6090400@kitware.com>

On 07/05/2016 03:39 PM, Konstantin Podsvirov wrote:
> I found a small bug in CPackIFW. The patch is attached.

Thanks, applied:

 CPackIFW: Fix attributes for Promoting Updates repository replacement
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a30fa1a

> Changes are best to send to a mailing list or use your gitlab?

Either is fine.  We're still experimenting with the GitLab
workflow so it is not documented in CONTRIBUTING.rst yet.

Thanks,
-Brad


From ruslan_baratov at yahoo.com  Tue Jul  5 16:13:52 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 5 Jul 2016 23:13:52 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <577C0493.7060303@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
Message-ID: <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>

On 05-Jul-16 22:03, Brad King wrote:
> On 07/01/2016 03:35 PM, Brad King wrote:
>> I don't think we should duplicate the
>>
>>    "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"
>>
>> expression.  The stripping of ?.* can be done earlier, or done as
>> part of the main match.
> Please try this commit:
>
>   ExternalProject: Match filenames in URLs with query strings and anchors
>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57c337e2
>
> Thanks,
> -Brad
>
Works fine on my tests. However I still vote for using default value for 
'fname' instead of FATAL_ERROR. If something bad will happen user always 
can use DOWNLOAD_NAME.

Example of the test that will fail with current version but works fine 
with default name:

    cmake_minimum_required(VERSION 3.5)

    include(ExternalProject)

    ExternalProject_Add(
         foo
         URL "http://tinyurl.com/jn86pmc"
         URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
         CONFIGURE_COMMAND ""
         BUILD_COMMAND ""
         INSTALL_COMMAND ""
    )

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160705/ff809fcb/attachment.html>

From konstantin at podsvirov.pro  Tue Jul  5 16:14:50 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 05 Jul 2016 23:14:50 +0300
Subject: [cmake-developers] Fix bug in CPack IFW Promoting Updates
	repository replacement
In-Reply-To: <577C114C.6090400@kitware.com>
References: <520951467747559@web11o.yandex.ru> <577C114C.6090400@kitware.com>
Message-ID: <596171467749690@web2g.yandex.ru>

Thanks again, Brad!

05.07.2016, 22:58, "Brad King" <brad.king at kitware.com>:
> On date 07/05/2016 03:39 PM, Konstantin Podsvirov wrote:
>> I found a small bug in CPackIFW. The patch is attached.
>
> Thanks, applied:
>
> CPackIFW: Fix attributes for Promoting Updates repository replacement
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a30fa1a
>
>> Changes are best to send to a mailing list or use your networks?
>
> Either is fine. We're still experimenting with the Networks
> workflow so it is not documented in the CONTRIBUTING.rst yet.

I apologize that sometimes there are persistent, but thank you so much for your feedback and applying my changes.

The theme of integration and CMake QtIFW quite new and deals with both technologies.

I get good feedback from CMake and try to influence the development of QtIFW.

The project QtIFW included in the Qt infrastructure and make changes to it is not so simple. But I'm trying. Here's my first change (it is still pending):

https://codereview.qt-project.org/#/c/163220

I want to go further and to provide CMakeLists.txt to build the QtIFW.
I'm working on this theme in a topic branch "topic-cmake-project" on your server:

http://git.podsvirov.pro/?p=qt/qtifw.git;a=shortlog;h=refs/heads/topic-cmake-project

It is very dirty now, but there are already some results.
The project QtIFW for normal operation requires linking with the static version of the Qt library. This is not standard practice and could have a positive impact on the detection and correction of errors in this case.

I hope that this topic will ever be merged with the project QtIFW.

--
Regards,
Konstantin Podsvirov

From brad.king at kitware.com  Tue Jul  5 16:26:10 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 16:26:10 -0400
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
 <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
Message-ID: <577C17E2.1040109@kitware.com>

On 07/05/2016 04:13 PM, Ruslan Baratov wrote:
> Works fine on my tests.

Thanks for testing!

> However I still vote for using default value for 'fname' instead
> of FATAL_ERROR.

I think that behavior would be surprising.

> If something bad will happen user always can use DOWNLOAD_NAME.
> 
> Example of the test that will fail with current version but works
> fine with default name:
> 
>         URL "http://tinyurl.com/jn86pmc"

In that case one can just use DOWNLOAD_NAME.  Auto-extraction of
the filename from the URL is a convenience for a common case, but
in principle DOWNLOAD_NAME could always be used.

-Brad


From brad.king at kitware.com  Tue Jul  5 16:31:38 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 5 Jul 2016 16:31:38 -0400
Subject: [cmake-developers] [patch] Document -H and -B
In-Reply-To: <cf0cdc31-0d7f-a180-b5de-2f306a185d45@yahoo.com>
References: <c391e994-cd36-a61c-05ee-7b86fbc28a99@yahoo.com>
 <5775738F.8000709@kitware.com>
 <a9dcf1b6-5434-cc83-8eec-f51736a6ff3f@yahoo.com>
 <57757E7B.9050904@kitware.com>
 <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com>
 <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com>
 <CALSpCT0n3jUUSuYD7SneoBT0suP5YB2CYUNsyP1=aLsLb013ZQ@mail.gmail.com>
 <a8a2d867-0fc1-1f22-b527-3982961ec370@yahoo.com>
 <CALSpCT115zzJgKz4=dS_yPkzf=xvCp10BTOfaj4osUReLbcoEQ@mail.gmail.com>
 <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com>
 <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
 <577668D9.5070104@kitware.com>
 <cf0cdc31-0d7f-a180-b5de-2f306a185d45@yahoo.com>
Message-ID: <577C192A.1050109@kitware.com>

On 07/05/2016 06:29 AM, Ruslan Baratov wrote:
> I don't see the point of introducing new options. Developers will still 
> use -H/-B because it's backward compatible, well known and will work 
> 100% because of internal CMake testing. That said if you want to improve 
> the current behavior of -H/-B (like confusing with --help/no spaces 
> between -H and <path-to-source-tree>) I can take a look. Otherwise I'm 
> not interested (usually it means that the improvement will be abandoned).

The conflict with the plain `-H` help option is another reason to
keep these options private.  I've outlined what is an acceptable
path to offer public options for this workflow.  If anyone wants
to do that then great.  Otherwise the status quo will persist.

-Brad


From ruslan_baratov at yahoo.com  Tue Jul  5 17:14:48 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 6 Jul 2016 00:14:48 +0300
Subject: [cmake-developers] [patch] One more pattern for extracting file
 name from URL
In-Reply-To: <577C17E2.1040109@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
 <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
 <577C17E2.1040109@kitware.com>
Message-ID: <36eb8066-3dfc-238f-bf67-38e20113304e@yahoo.com>

On 05-Jul-16 23:26, Brad King wrote:
> On 07/05/2016 04:13 PM, Ruslan Baratov wrote:
>> Works fine on my tests.
> Thanks for testing!
>
>> However I still vote for using default value for 'fname' instead
>> of FATAL_ERROR.
> I think that behavior would be surprising.
Not such surprising as some error in internal CMake module with no 
detail description how it can be fixed. My point is that if it will work 
in most cases then why not? Most users will not even notice this.

>
>> If something bad will happen user always can use DOWNLOAD_NAME.
>>
>> Example of the test that will fail with current version but works
>> fine with default name:
>>
>>          URL "http://tinyurl.com/jn86pmc"
> In that case one can just use DOWNLOAD_NAME.  Auto-extraction of
> the filename from the URL is a convenience for a common case, but
> in principle DOWNLOAD_NAME could always be used.
The problem with DOWNLOAD_NAME is about generalizing code. If I have 100 
ExternalProject_Add commands with such URLs then I have to add 100 
DOWNLOAD_NAME. In my case I have a bunch of templates for 
ExternalProject_Add and to introduce this feature either I have:
* test URL for the pattern in similar way CMake do and predict the fact 
that CMake will fail to extract name (not stable, what if CMake logic 
changed? DRY violation)
* force some name unconditionally like archive.tar (most of the projects 
works fine and now for no reason archives will have another names)
* add about 20-30 lines of code to core modules, for each 
ExternalProject_Add template add parsing logic and 1 line for each 
package version declaration on user side

And all this without introducing any useful features, just to suppress 
CMake error for 0.01% of cases.

Anyway I've found workaround that I will use for such URLs. According to 
my tests most of the servers ignore fragments in URL and CMake can 
extract name from them. E.g. this works:

    cmake_minimum_required(VERSION 3.5)

    include(ExternalProject)

    ExternalProject_Add(
         foo
         URL "http://tinyurl.com/jn86pmc#a.tar"
         URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
         CONFIGURE_COMMAND ""
         BUILD_COMMAND ""
         INSTALL_COMMAND ""
    )

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160706/303ae9a8/attachment.html>

From dave.gittins at gmail.com  Tue Jul  5 18:02:00 2016
From: dave.gittins at gmail.com (Dave Gittins)
Date: Wed, 6 Jul 2016 08:02:00 +1000
Subject: [cmake-developers] [patch] Document -H and -B
In-Reply-To: <CAB4NfKQbXkVOPgn=kGnHvuDDen=ZskYLhxR=Sdv_29jVpFk_og@mail.gmail.com>
References: <c391e994-cd36-a61c-05ee-7b86fbc28a99@yahoo.com>
 <5775738F.8000709@kitware.com>
 <a9dcf1b6-5434-cc83-8eec-f51736a6ff3f@yahoo.com>
 <57757E7B.9050904@kitware.com>
 <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com>
 <577583AA.90006@kitware.com>
 <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com>
 <CALSpCT0n3jUUSuYD7SneoBT0suP5YB2CYUNsyP1=aLsLb013ZQ@mail.gmail.com>
 <a8a2d867-0fc1-1f22-b527-3982961ec370@yahoo.com>
 <CALSpCT115zzJgKz4=dS_yPkzf=xvCp10BTOfaj4osUReLbcoEQ@mail.gmail.com>
 <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com>
 <CAB4NfKTKfKNEWu51wwkZRn+Js1=zV3FX_-ZF6Hwf=skSutwOSg@mail.gmail.com>
 <577668D9.5070104@kitware.com>
 <cf0cdc31-0d7f-a180-b5de-2f306a185d45@yahoo.com>
 <577C192A.1050109@kitware.com>
 <CAB4NfKQbXkVOPgn=kGnHvuDDen=ZskYLhxR=Sdv_29jVpFk_og@mail.gmail.com>
Message-ID: <CAB4NfKS30EZpxwxR+--JsCL6ETWFmf1rzom=XOFS2vS3sibG9A@mail.gmail.com>

I think we should add new normalised forms but still mention the deprecated
names in the docs.

You can't put the cat back in the bag - like it or not, those option names
seem quite widely used. Developers will join a project and see them in use.
Currently they will find no mention of them in docs but find something on
StackOverflow (which may or may not be accurate), and they will stay like
that even if new forms are available. That's what I observe in the field.

If you explain in docs that they are deprecated forms, those developers
will know what they actually do and that they are deprecated, and many will
replace with the new form.

I believe those are your choices basically; I am really hoping you choose
the latter!

Dave
On 6 Jul 2016 06:31, "Brad King" <brad.king at kitware.com> wrote:

On 07/05/2016 06:29 AM, Ruslan Baratov wrote:
> I don't see the point of introducing new options. Developers will still
> use -H/-B because it's backward compatible, well known and will work
> 100% because of internal CMake testing. That said if you want to improve
> the current behavior of -H/-B (like confusing with --help/no spaces
> between -H and <path-to-source-tree>) I can take a look. Otherwise I'm
> not interested (usually it means that the improvement will be abandoned).

The conflict with the plain `-H` help option is another reason to
keep these options private.  I've outlined what is an acceptable
path to offer public options for this workflow.  If anyone wants
to do that then great.  Otherwise the status quo will persist.

-Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160706/772070b5/attachment.html>

From Geoffrey.Viola at asirobots.com  Tue Jul  5 23:51:31 2016
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Wed, 6 Jul 2016 03:51:31 +0000
Subject: [cmake-developers] Green Hills MULTI Generator Recommendations
In-Reply-To: <CAAAjsBoLPf9_ajf=td1_XwEX4mVUVfo2Q-pdascyotMyjcMxJQ@mail.gmail.com>
References: <CAAAjsBoLPf9_ajf=td1_XwEX4mVUVfo2Q-pdascyotMyjcMxJQ@mail.gmail.com>
Message-ID: <BY2PR07MB1556B4D236505235BFFE9550893A0@BY2PR07MB1556.namprd07.prod.outlook.com>

> I am interested in using CMake with Green Hills MULTI
Great!

> 2. Is there a way in a toolchain file or on the command line to specify the directory where CMake should look for the compiler executables?
Take a look at https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalGhsMultiGenerator.cxx#L50-82. It's hard coded to find gbuild and the Green Hills arm compiler. Ideally it would find an arbitrary compiler on the system, unless specified in the toolchain file. Probably, CMake should search with some priority like x86 and then the others.

For a typical use case, you can take a look at the tests https://gitlab.kitware.com/cmake/cmake/blob/master/Tests/CMakeLists.txt#L2113-2139. There are two GHS specific test projects: Tests/GhsMulti and Tests/GhsMultiDuplicateSourceFilenames. These run nightly. Ideally, you should be able to run them without specifying anything arm related. The tests only confirms that it configures and compiles without errors. I use these as test projects, when developing.

This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

From brad.king at kitware.com  Wed Jul  6 10:36:55 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 6 Jul 2016 10:36:55 -0400
Subject: [cmake-developers] ExternalProject default downloaded file name
In-Reply-To: <36eb8066-3dfc-238f-bf67-38e20113304e@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
 <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
 <577C17E2.1040109@kitware.com>
 <36eb8066-3dfc-238f-bf67-38e20113304e@yahoo.com>
Message-ID: <577D1787.8050503@kitware.com>

On 07/05/2016 05:14 PM, Ruslan Baratov wrote:
> if it will work in most cases then why not? Most users will not
> even notice this.

Okay.  The changes for the new pattern are now in `master` and
are worthwhile regardless of having a default filename fallback
because they help extract a more readable name in more cases.

Please rebase your default filename fallback on that.

Thanks,
-Brad


From ruslan_baratov at yahoo.com  Wed Jul  6 12:07:50 2016
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 6 Jul 2016 19:07:50 +0300
Subject: [cmake-developers] ExternalProject default downloaded file name
In-Reply-To: <577D1787.8050503@kitware.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
 <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
 <577C17E2.1040109@kitware.com>
 <36eb8066-3dfc-238f-bf67-38e20113304e@yahoo.com>
 <577D1787.8050503@kitware.com>
Message-ID: <f0c15bd1-53a8-bc7c-b403-540be6dfbed9@yahoo.com>

Attaching rebased patch.

Thanks!

On 06-Jul-16 17:36, Brad King wrote:
> On 07/05/2016 05:14 PM, Ruslan Baratov wrote:
>> if it will work in most cases then why not? Most users will not
>> even notice this.
> Okay.  The changes for the new pattern are now in `master` and
> are worthwhile regardless of having a default filename fallback
> because they help extract a more readable name in more cases.
>
> Please rebase your default filename fallback on that.
>
> Thanks,
> -Brad
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-default-filename-if-extracting-from-URL-failed.patch
Type: text/x-patch
Size: 1130 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160706/dfbf5db9/attachment.bin>

From davispuh at gmail.com  Wed Jul  6 15:12:07 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:07 +0300
Subject: [cmake-developers] [PATCH v3 1/7] On Windows use correct encoding
	for SystemTools::GetEnv
Message-ID: <20160706191213.16242-1-davispuh@gmail.com>

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
instead and encode that.

Also add SystemTools::HasEnv function.
---
 Source/kwsys/SystemTools.cxx    | 56 ++++++++++++++++++++++++++++++++++-------
 Source/kwsys/SystemTools.hxx.in |  2 ++
 2 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..2b1db4d 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -468,16 +468,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+    result = Encoding::ToNarrow(wv);
+    return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-    {
+  if (v) {
     result = v;
     return true;
-    }
-  else
-    {
-    return false;
-    }
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -485,6 +490,22 @@ bool SystemTools::GetEnv(const std::string& key, std::string& result)
   return SystemTools::GetEnv(key.c_str(), result);
 }
 
+bool SystemTools::HasEnv(const char* key)
+{
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* v = _wgetenv(wkey.c_str());
+#else
+  const char* v = getenv(key);
+#endif
+  return v != 0;
+}
+
+bool SystemTools::HasEnv(const std::string& key)
+{
+  return SystemTools::HasEnv(key.c_str());
+}
+
 //----------------------------------------------------------------------------
 
 #if defined(__CYGWIN__) || defined(__GLIBC__)
@@ -533,13 +554,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0)
     {
     err = errno;
     }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
     {
     err = errno;
     }
@@ -679,7 +712,12 @@ public:
     static_cast<void>(oldEnv);
     char* newEnv = strdup(env);
     this->insert(newEnv);
+#if defined(_WIN32)
+    const std::wstring wEnv = Encoding::ToWide(newEnv);
+    return _wputenv(wEnv.c_str()) == 0;
+#else
     return putenv(newEnv) == 0;
+#endif
     }
   bool UnPut(const char* env)
     {
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..c9b18b7 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -843,6 +843,8 @@ public:
   static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
+  static bool HasEnv(const char* key);
+  static bool HasEnv(const std::string& key);
 
   /** Put a string into the environment
       of the form var=value */
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:08 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:08 +0300
Subject: [cmake-developers] [PATCH v3 2/7] Deprecate const char*
	SystemTools::GetEnv function
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-2-davispuh@gmail.com>

On Windows this function returns environment variable encoded
in ANSI codepage which might not match internally used encoding.
---
 Source/kwsys/SystemTools.hxx.in | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index c9b18b7..51fb206 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -26,6 +26,16 @@
 # include <unistd.h> // For access permissions for use with access()
 #endif
 
+#if __cplusplus >= 201402L
+# define DEPRECATED [[deprecated]]
+#elif defined(__GNUC__)
+# define DEPRECATED __attribute__ ((deprecated))
+#elif defined(_MSC_VER)
+# define DEPRECATED __declspec(deprecated)
+#else
+# define DEPRECATED
+#endif
+
 // Required for va_list
 #include <stdarg.h>
 // Required for FILE*
@@ -839,8 +849,8 @@ public:
   /**
    * Read an environment variable
    */
-  static const char* GetEnv(const char* key);
-  static const char* GetEnv(const std::string& key);
+  DEPRECATED static const char* GetEnv(const char* key);
+  DEPRECATED static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
   static bool HasEnv(const char* key);
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:10 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:10 +0300
Subject: [cmake-developers] [PATCH v3 4/7] For Windows encode process output
	to internally used encoding
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-4-davispuh@gmail.com>

Typically Windows applications (eg. MSVC compiler) use current console's
codepage for output to pipes so we need to encode that to internally used
encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
---
 Source/kwsys/CMakeLists.txt |  2 ++
 Source/kwsys/ProcessWin32.c | 25 ++++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 39b03b3..65203c0 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -708,6 +708,8 @@ IF(KWSYS_USE_Process)
   IF(NOT UNIX)
     # Use the Windows implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessWin32.c)
+    SET_PROPERTY(SOURCE ProcessWin32.c APPEND PROPERTY COMPILE_DEFINITIONS
+      KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
   ELSE()
     # Use the UNIX implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessUNIX.c)
diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
index 2b93e69..153dc0b 100644
--- a/Source/kwsys/ProcessWin32.c
+++ b/Source/kwsys/ProcessWin32.c
@@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
   /* ------------- Data managed per call to Execute ------------- */
 
   /* Buffer for data read in this pipe's thread.  */
-  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
+  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];
 
   /* The length of the data stored in the buffer.  */
   DWORD DataLength;
@@ -319,6 +319,9 @@ struct kwsysProcess_s
   /* Own handles for the child's ends of the pipes in the parent process.
      Used temporarily during process creation.  */
   HANDLE PipeChildStd[3];
+
+  /* Console's active codepage */
+  UINT codepage;
 };
 
 /*--------------------------------------------------------------------------*/
@@ -1626,6 +1629,21 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp, kwsysProcessPipeData* td)
       KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
       }
 
+    if (td->DataLength > 0) {
+      if (cp->codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
+        const int wlength = MultiByteToWideChar(cp->codepage, 0, td->DataBuffer, td->DataLength, NULL, 0);
+        wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
+        int r = MultiByteToWideChar(cp->codepage, 0, td->DataBuffer, td->DataLength, wdata, wlength);
+        if (r > 0) {
+          r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0, wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
+          if (r > 0) {
+            td->DataLength = r;
+          }
+        }
+        free(wdata);
+      }
+    }
+
     KWSYSPE_DEBUG((stderr, "read %d\n", td->Index));
 
     /* Wait for our turn to be handled by the main thread.  */
@@ -1761,6 +1779,11 @@ int kwsysProcessInitialize(kwsysProcess* cp)
     }
   }
 
+  cp->codepage = GetConsoleCP();
+  if (!cp->codepage) {
+    cp->codepage = GetACP();
+  }
+
   return 1;
 }
 
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:09 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:09 +0300
Subject: [cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and
	HasEnv functions
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-3-davispuh@gmail.com>

---
 Source/CPack/cmCPackGenerator.cxx           |  8 +++---
 Source/CTest/cmCTestCoverageHandler.cxx     | 12 ++++-----
 Source/CTest/cmCTestCurl.cxx                | 27 ++++++++++----------
 Source/CTest/cmCTestMultiProcessHandler.cxx |  8 +++---
 Source/cmBuildCommand.cxx                   | 25 +++++++++----------
 Source/cmCLocaleEnvironmentScope.cxx        |  5 ++--
 Source/cmCTest.cxx                          | 11 +++++----
 Source/cmCommandArgumentParserHelper.cxx    |  8 +++---
 Source/cmConditionEvaluator.cxx             |  2 +-
 Source/cmExportCommand.cxx                  |  5 ++--
 Source/cmExtraEclipseCDT4Generator.cxx      |  9 ++++---
 Source/cmFileCommand.cxx                    | 11 +++++----
 Source/cmFindPackageCommand.cxx             |  4 +--
 Source/cmGlobalVisualStudio7Generator.cxx   |  6 ++---
 Source/cmMakefile.cxx                       |  5 +++-
 Source/cmNinjaTargetGenerator.cxx           |  2 +-
 Source/cmQtAutoGenerators.cxx               |  2 +-
 Source/cmSetCommand.cxx                     |  7 +++---
 Source/cmState.cxx                          |  5 ++--
 Source/cmSystemTools.cxx                    |  6 ++---
 Source/cmTimestamp.cxx                      |  7 +++---
 Source/cmUtils.hxx                          | 26 ++++++++++++++++++++
 Source/cmake.cxx                            | 21 +++++-----------
 Source/cmcmd.cxx                            | 16 +++++-------
 Source/kwsys/SystemInformation.cxx          | 20 +++++++--------
 Source/kwsys/SystemTools.cxx                | 38 +++++++++++------------------
 Source/kwsys/testSystemTools.cxx            |  9 ++++---
 27 files changed, 156 insertions(+), 149 deletions(-)
 create mode 100644 Source/cmUtils.hxx

diff --git a/Source/CPack/cmCPackGenerator.cxx b/Source/CPack/cmCPackGenerator.cxx
index df8bb0f..76609e1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1074,11 +1074,11 @@ const char* cmCPackGenerator::GetInstallPath()
     return this->InstallPath.c_str();
   }
 #if defined(_WIN32) && !defined(__CYGWIN__)
-  const char* prgfiles = cmsys::SystemTools::GetEnv("ProgramFiles");
-  const char* sysDrive = cmsys::SystemTools::GetEnv("SystemDrive");
-  if (prgfiles) {
+  std::string prgfiles;
+  std::string sysDrive;
+  if (cmsys::SystemTools::GetEnv("ProgramFiles", prgfiles)) {
     this->InstallPath = prgfiles;
-  } else if (sysDrive) {
+  } else if (cmsys::SystemTools::GetEnv("SystemDrive", sysDrive)) {
     this->InstallPath = sysDrive;
     this->InstallPath += "/Program Files";
   } else {
diff --git a/Source/CTest/cmCTestCoverageHandler.cxx b/Source/CTest/cmCTestCoverageHandler.cxx
index 7102533..9410a52 100644
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@ -727,10 +727,7 @@ int cmCTestCoverageHandler::HandleCoberturaCoverage(
   // if it doesn't exist or is empty, assume the
   // binary directory is used.
   std::string coverageXMLFile;
-  const char* covDir = cmSystemTools::GetEnv("COBERTURADIR");
-  if (covDir && strlen(covDir) != 0) {
-    coverageXMLFile = std::string(covDir);
-  } else {
+  if (!cmSystemTools::GetEnv("COBERTURADIR", coverageXMLFile) || coverageXMLFile.empty()) {
     coverageXMLFile = this->CTest->GetBinaryDir();
   }
   // build the find file string with the directory from above
@@ -791,7 +788,8 @@ struct cmCTestCoverageHandlerLocale
 {
   cmCTestCoverageHandlerLocale()
   {
-    if (const char* l = cmSystemTools::GetEnv("LC_ALL")) {
+    std::string l;
+    if (cmSystemTools::GetEnv("LC_ALL", l)) {
       lc_all = l;
     }
     if (lc_all != "C") {
@@ -2121,8 +2119,8 @@ int cmCTestCoverageHandler::RunBullseyeSourceSummary(
 int cmCTestCoverageHandler::HandleBullseyeCoverage(
   cmCTestCoverageHandlerContainer* cont)
 {
-  const char* covfile = cmSystemTools::GetEnv("COVFILE");
-  if (!covfile || strlen(covfile) == 0) {
+  std::string covfile;
+  if (!cmSystemTools::GetEnv("COVFILE", covfile) || covfile.empty()) {
     cmCTestOptionalLog(this->CTest, HANDLER_VERBOSE_OUTPUT,
                        " COVFILE environment variable not found, not running "
                        " bullseye\n",
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index 6b8e5b5..b335e32 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -219,16 +219,18 @@ bool cmCTestCurl::HttpRequest(std::string const& url,
 
 void cmCTestCurl::SetProxyType()
 {
-  if (cmSystemTools::GetEnv("HTTP_PROXY")) {
-    this->HTTPProxy = cmSystemTools::GetEnv("HTTP_PROXY");
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT")) {
+  this->HTTPProxy = "";
+  // this is the default
+  this->HTTPProxyType = CURLPROXY_HTTP;
+  this->HTTPProxyAuth = "";
+  if (cmSystemTools::GetEnv("HTTP_PROXY", this->HTTPProxy)) {
+    std::string port;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT", port)) {
       this->HTTPProxy += ":";
-      this->HTTPProxy += cmSystemTools::GetEnv("HTTP_PROXY_PORT");
+      this->HTTPProxy += port;
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE")) {
-      // this is the default
-      this->HTTPProxyType = CURLPROXY_HTTP;
-      std::string type = cmSystemTools::GetEnv("HTTP_PROXY_TYPE");
+    std::string type;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE", type)) {
       // HTTP/SOCKS4/SOCKS5
       if (type == "HTTP") {
         this->HTTPProxyType = CURLPROXY_HTTP;
@@ -238,12 +240,11 @@ void cmCTestCurl::SetProxyType()
         this->HTTPProxyType = CURLPROXY_SOCKS5;
       }
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_USER")) {
-      this->HTTPProxyAuth = cmSystemTools::GetEnv("HTTP_PROXY_USER");
-    }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD")) {
+    cmSystemTools::GetEnv("HTTP_PROXY_USER", this->HTTPProxyAuth);
+    std::string passwd;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD", passwd)) {
       this->HTTPProxyAuth += ":";
-      this->HTTPProxyAuth += cmSystemTools::GetEnv("HTTP_PROXY_PASSWD");
+      this->HTTPProxyAuth += passwd;
     }
   }
 }
diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx b/Source/CTest/cmCTestMultiProcessHandler.cxx
index ae97d32..ffd51c7 100644
--- a/Source/CTest/cmCTestMultiProcessHandler.cxx
+++ b/Source/CTest/cmCTestMultiProcessHandler.cxx
@@ -261,12 +261,12 @@ void cmCTestMultiProcessHandler::StartNextTests()
     allTestsFailedTestLoadCheck = true;
 
     // Check for a fake load average value used in testing.
-    if (const char* fake_load_value =
-          cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING")) {
+    std::string fake_load_value;
+    if (cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING", fake_load_value)) {
       usedFakeLoadForTesting = true;
-      if (!cmSystemTools::StringToULong(fake_load_value, &systemLoad)) {
+      if (!cmSystemTools::StringToULong(fake_load_value.c_str(), &systemLoad)) {
         cmSystemTools::Error("Failed to parse fake load value: ",
-                             fake_load_value);
+                             fake_load_value.c_str());
       }
     }
     // If it's not set, look up the true load average.
diff --git a/Source/cmBuildCommand.cxx b/Source/cmBuildCommand.cxx
index fb143a2..3dfd9cf 100644
--- a/Source/cmBuildCommand.cxx
+++ b/Source/cmBuildCommand.cxx
@@ -36,8 +36,8 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   const char* variable = args[0].c_str();
 
   // Parse remaining arguments.
-  const char* configuration = CM_NULLPTR;
-  const char* project_name = CM_NULLPTR;
+  std::string configuration;
+  std::string project_name;
   std::string target;
   enum Doing
   {
@@ -56,10 +56,10 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
       doing = DoingTarget;
     } else if (doing == DoingConfiguration) {
       doing = DoingNone;
-      configuration = args[i].c_str();
+      configuration = args[i];
     } else if (doing == DoingProjectName) {
       doing = DoingNone;
-      project_name = args[i].c_str();
+      project_name = args[i];
     } else if (doing == DoingTarget) {
       doing = DoingNone;
       target = args[i];
@@ -76,14 +76,14 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   // so we put this code here to end up with the same default configuration
   // as the original 2-arg build_command signature:
   //
-  if (!configuration || !*configuration) {
-    configuration = getenv("CMAKE_CONFIG_TYPE");
+  if (configuration.empty()) {
+    cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configuration);
   }
-  if (!configuration || !*configuration) {
+  if (configuration.empty()) {
     configuration = "Release";
   }
 
-  if (project_name && *project_name) {
+  if (!project_name.empty()) {
     this->Makefile->IssueMessage(
       cmake::AUTHOR_WARNING,
       "Ignoring PROJECT_NAME option because it has no effect.");
@@ -91,7 +91,7 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
 
   std::string makecommand =
     this->Makefile->GetGlobalGenerator()->GenerateCMakeBuildCommand(
-      target, configuration, "", this->Makefile->IgnoreErrorsCMP0061());
+      target, configuration.c_str(), "", this->Makefile->IgnoreErrorsCMP0061());
 
   this->Makefile->AddDefinition(variable, makecommand.c_str());
 
@@ -108,10 +108,9 @@ bool cmBuildCommand::TwoArgsSignature(std::vector<std::string> const& args)
   const char* define = args[0].c_str();
   const char* cacheValue = this->Makefile->GetDefinition(define);
 
-  std::string configType = "Release";
-  const char* cfg = getenv("CMAKE_CONFIG_TYPE");
-  if (cfg && *cfg) {
-    configType = cfg;
+  std::string configType;
+  if (!cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configType) || configType.empty()) {
+    configType = "Release";
   }
 
   std::string makecommand =
diff --git a/Source/cmCLocaleEnvironmentScope.cxx b/Source/cmCLocaleEnvironmentScope.cxx
index a19dbae..e4c74ec 100644
--- a/Source/cmCLocaleEnvironmentScope.cxx
+++ b/Source/cmCLocaleEnvironmentScope.cxx
@@ -31,8 +31,9 @@ cmCLocaleEnvironmentScope::cmCLocaleEnvironmentScope()
 
 std::string cmCLocaleEnvironmentScope::GetEnv(std::string const& key)
 {
-  const char* value = cmSystemTools::GetEnv(key);
-  return value ? value : std::string();
+  std::string value;
+  cmSystemTools::GetEnv(key, value);
+  return value;
 }
 
 void cmCLocaleEnvironmentScope::SetEnv(std::string const& key,
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 3bb997a..05dd245 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -298,9 +298,9 @@ cmCTest::cmCTest()
   this->ComputedCompressMemCheckOutput = false;
   this->RepeatTests = 1; // default to run each test once
   this->RepeatUntilFail = false;
-  if (const char* outOnFail =
-        cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE")) {
-    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail);
+  std::string outOnFail;
+  if (cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE", outOnFail)) {
+    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail.c_str());
   }
   this->InitStreams();
 
@@ -2091,8 +2091,9 @@ int cmCTest::Run(std::vector<std::string>& args, std::string* output)
 
   // handle CTEST_PARALLEL_LEVEL environment variable
   if (!this->ParallelLevelSetInCli) {
-    if (const char* parallel = cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL")) {
-      int plevel = atoi(parallel);
+    std::string parallel;
+    if (cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL", parallel)) {
+      int plevel = atoi(parallel.c_str());
       this->SetParallelLevel(plevel);
     }
   }
diff --git a/Source/cmCommandArgumentParserHelper.cxx b/Source/cmCommandArgumentParserHelper.cxx
index 294117c..42fb105 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -71,12 +71,12 @@ char* cmCommandArgumentParserHelper::ExpandSpecialVariable(const char* key,
     return this->EmptyVariable;
   }
   if (strcmp(key, "ENV") == 0) {
-    char* ptr = getenv(var);
-    if (ptr) {
+    std::string str;
+    if (cmSystemTools::GetEnv(var, str)) {
       if (this->EscapeQuotes) {
-        return this->AddString(cmSystemTools::EscapeQuotes(ptr));
+        return this->AddString(cmSystemTools::EscapeQuotes(str.c_str()));
       } else {
-        return ptr;
+        return this->AddString(str);
       }
     }
     return this->EmptyVariable;
diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 67b2571..e02221c 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -486,7 +486,7 @@ bool cmConditionEvaluator::HandleLevel1(cmArgumentList& newArgs, std::string&,
         if (argP1len > 4 && argP1->GetValue().substr(0, 4) == "ENV{" &&
             argP1->GetValue().operator[](argP1len - 1) == '}') {
           std::string env = argP1->GetValue().substr(4, argP1len - 5);
-          bdef = cmSystemTools::GetEnv(env.c_str()) ? true : false;
+          bdef = cmSystemTools::HasEnv(env.c_str());
         } else {
           bdef = this->Makefile.IsDefinitionSet(argP1->GetValue());
         }
diff --git a/Source/cmExportCommand.cxx b/Source/cmExportCommand.cxx
index 3cb575e..fc62492 100644
--- a/Source/cmExportCommand.cxx
+++ b/Source/cmExportCommand.cxx
@@ -327,11 +327,10 @@ void cmExportCommand::StorePackageRegistryDir(std::string const& package,
   fname += "/cmake/packages/";
   fname += package;
 #else
-  const char* home = cmSystemTools::GetEnv("HOME");
-  if (!home) {
+  std::string fname;
+  if (!cmSystemTools::GetEnv("HOME", fname)) {
     return;
   }
-  std::string fname = home;
   cmSystemTools::ConvertToUnixSlashes(fname);
   fname += "/.cmake/packages/";
   fname += package;
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx
index 16cb082..93c55cc 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -208,7 +208,8 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
   // get the variables from the environment and from the cache and then
   // figure out which one to use:
 
-  const char* envVarValue = getenv(envVar);
+  std::string envVarValue;
+  const bool envVarSet = cmSystemTools::GetEnv(envVar, envVarValue);
 
   std::string cacheEntryName = "CMAKE_ECLIPSE_ENVVAR_";
   cacheEntryName += envVar;
@@ -217,17 +218,17 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
 
   // now we have both, decide which one to use
   std::string valueToUse;
-  if (envVarValue == CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  if (!envVarSet && cacheValue == CM_NULLPTR) {
     // nothing known, do nothing
     valueToUse = "";
-  } else if (envVarValue != CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  } else if (envVarSet && cacheValue == CM_NULLPTR) {
     // The variable is in the env, but not in the cache. Use it and put it
     // in the cache
     valueToUse = envVarValue;
     mf->AddCacheDefinition(cacheEntryName, valueToUse.c_str(),
                            cacheEntryName.c_str(), cmState::STRING, true);
     mf->GetCMakeInstance()->SaveCache(lg->GetBinaryDirectory());
-  } else if (envVarValue == CM_NULLPTR && cacheValue != CM_NULLPTR) {
+  } else if (!envVarSet && cacheValue != CM_NULLPTR) {
     // It is already in the cache, but not in the env, so use it from the cache
     valueToUse = cacheValue;
   } else {
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 5a1238b..835b118 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -1609,8 +1609,10 @@ struct cmFileInstaller : public cmFileCopier
     // Installation does not use source permissions by default.
     this->UseSourcePermissions = false;
     // Check whether to copy files always or only if they have changed.
-    this->Always =
-      cmSystemTools::IsOn(cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS"));
+    std::string install_always;
+    if (cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS", install_always)) {
+      this->Always = cmSystemTools::IsOn(install_always.c_str());
+    }
     // Get the current manifest.
     this->Manifest =
       this->Makefile->GetSafeDefinition("CMAKE_INSTALL_MANIFEST_FILES");
@@ -1869,9 +1871,8 @@ bool cmFileInstaller::HandleInstallDestination()
     return false;
   }
 
-  const char* destdir = cmSystemTools::GetEnv("DESTDIR");
-  if (destdir && *destdir) {
-    std::string sdestdir = destdir;
+  std::string sdestdir;
+  if (cmSystemTools::GetEnv("DESTDIR", sdestdir) && !sdestdir.empty()) {
     cmSystemTools::ConvertToUnixSlashes(sdestdir);
     char ch1 = destination[0];
     char ch2 = destination[1];
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index d5fd75d..260079b 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1077,8 +1077,8 @@ void cmFindPackageCommand::FillPrefixesUserRegistry()
                                  this->LabeledPaths[PathLabel::UserRegistry]);
   }
 #else
-  if (const char* home = cmSystemTools::GetEnv("HOME")) {
-    std::string dir = home;
+  std::string dir;
+  if (cmSystemTools::GetEnv("HOME", dir)) {
     dir += "/.cmake/packages/";
     dir += this->Name;
     this->LoadPackageRegistryDir(dir,
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx b/Source/cmGlobalVisualStudio7Generator.cxx
index 262909f..0a83b3a 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -122,9 +122,9 @@ void cmGlobalVisualStudio7Generator::EnableLanguage(
   // does not use the environment it is run in, and this allows
   // for running commands and using dll's that the IDE environment
   // does not know about.
-  const char* extraPath = cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH");
-  if (extraPath) {
-    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath,
+  std::string extraPath;
+  if (cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH", extraPath)) {
+    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath.c_str(),
                            "Saved environment variable CMAKE_MSVCIDE_RUN_PATH",
                            cmState::STATIC);
   }
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 0d550dd..ab7de57 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2572,6 +2572,7 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
           std::string const& lookup = result.substr(var.loc);
           const char* value = CM_NULLPTR;
           std::string varresult;
+          std::string svalue;
           static const std::string lineVar = "CMAKE_CURRENT_LIST_LINE";
           switch (var.domain) {
             case NORMAL:
@@ -2584,7 +2585,9 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
               }
               break;
             case ENVIRONMENT:
-              value = cmSystemTools::GetEnv(lookup.c_str());
+              if (cmSystemTools::GetEnv(lookup, svalue)) {
+                value = svalue.c_str();
+              }
               break;
             case CACHE:
               value = state->GetCacheEntryValue(lookup);
diff --git a/Source/cmNinjaTargetGenerator.cxx b/Source/cmNinjaTargetGenerator.cxx
index 1d3e608..855a243 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -741,5 +741,5 @@ bool cmNinjaTargetGenerator::ForceResponseFile()
 {
   static std::string const forceRspFile = "CMAKE_NINJA_FORCE_RESPONSE_FILE";
   return (this->GetMakefile()->IsDefinitionSet(forceRspFile) ||
-          cmSystemTools::GetEnv(forceRspFile) != CM_NULLPTR);
+          cmSystemTools::HasEnv(forceRspFile));
 }
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 4b40c08..b821fda 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -88,7 +88,7 @@ static std::string extractSubDir(const std::string& absPath,
 }
 
 cmQtAutoGenerators::cmQtAutoGenerators()
-  : Verbose(cmsys::SystemTools::GetEnv("VERBOSE") != CM_NULLPTR)
+  : Verbose(cmsys::SystemTools::HasEnv("VERBOSE"))
   , ColorOutput(true)
   , RunMocFailed(false)
   , RunUicFailed(false)
diff --git a/Source/cmSetCommand.cxx b/Source/cmSetCommand.cxx
index 1484368..8fb6aa0 100644
--- a/Source/cmSetCommand.cxx
+++ b/Source/cmSetCommand.cxx
@@ -31,13 +31,14 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
     putEnvArg += "=";
 
     // what is the current value if any
-    const char* currValue = getenv(varName);
+    std::string currValue;
+    const bool currValueSet = cmSystemTools::GetEnv(varName, currValue);
     delete[] varName;
 
     // will it be set to something, then set it
     if (args.size() > 1 && !args[1].empty()) {
       // but only if it is different from current value
-      if (!currValue || strcmp(currValue, args[1].c_str())) {
+      if (!currValueSet || currValue != args[1]) {
         putEnvArg += args[1];
         cmSystemTools::PutEnv(putEnvArg);
       }
@@ -45,7 +46,7 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
     }
 
     // if it will be cleared, then clear it if it isn't already clear
-    if (currValue) {
+    if (currValueSet) {
       cmSystemTools::PutEnv(putEnvArg);
     }
     return true;
diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index f2fe134..0470508 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -1286,8 +1286,9 @@ void cmState::Snapshot::SetDefaultDefinitions()
   this->SetDefinition("CMAKE_HOST_UNIX", "1");
 #endif
 #if defined(__CYGWIN__)
-  if (cmSystemTools::IsOn(
-        cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32"))) {
+  std::string legacy;
+  if (cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32", legacy) &&
+      cmSystemTools::IsOn(legacy.c_str())) {
     this->SetDefinition("WIN32", "1");
     this->SetDefinition("CMAKE_HOST_WIN32", "1");
   }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 2d463f3..9740ef7 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2069,9 +2069,9 @@ void cmSystemTools::MakefileColorEcho(int color, const char* message,
   // However, we can test for some situations when the answer is most
   // likely no.
   int assumeTTY = cmsysTerminal_Color_AssumeTTY;
-  if (cmSystemTools::GetEnv("DART_TEST_FROM_DART") ||
-      cmSystemTools::GetEnv("DASHBOARD_TEST_FROM_CTEST") ||
-      cmSystemTools::GetEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
+  if (cmSystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      cmSystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST") ||
+      cmSystemTools::HasEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
     // Avoid printing color escapes during dashboard builds.
     assumeTTY = 0;
   }
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index c3c1d17..61b74db 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -93,10 +93,9 @@ time_t cmTimestamp::CreateUtcTimeTFromTm(struct tm& tm) const
 #else
   // From Linux timegm() manpage.
 
-  std::string tz_old = "TZ=";
-  if (const char* tz = cmSystemTools::GetEnv("TZ")) {
-    tz_old += tz;
-  }
+  std::string tz_old = "";
+  cmSystemTools::GetEnv("TZ", tz_old);
+  tz_old = "TZ=" + tz_old;
 
   // The standard says that "TZ=" or "TZ=[UNRECOGNIZED_TZ]" means UTC.
   // It seems that "TZ=" does NOT work, at least under Windows
diff --git a/Source/cmUtils.hxx b/Source/cmUtils.hxx
new file mode 100644
index 0000000..fd1031e
--- /dev/null
+++ b/Source/cmUtils.hxx
@@ -0,0 +1,26 @@
+/*============================================================================
+  CMake - Cross Platform Makefile Generator
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef cmUtils_hxx
+#define cmUtils_hxx
+
+#include <cmsys/SystemTools.hxx>
+
+// Use the make system's VERBOSE environment variable to enable
+// verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
+// (which is set by the Eclipse and KDevelop generators).
+inline bool isCMakeVerbose() {
+  return (cmSystemTools::HasEnv("VERBOSE") &&
+          !cmSystemTools::HasEnv("CMAKE_NO_VERBOSE"));
+}
+
+#endif
+
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index c597605..e4a9954 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -22,6 +22,7 @@
 #include "cmSourceFile.h"
 #include "cmState.h"
 #include "cmTest.h"
+#include "cmUtils.hxx"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmGraphVizWriter.h"
@@ -955,16 +956,10 @@ void cmake::SetGlobalGenerator(cmGlobalGenerator* gg)
   cmSystemTools::SetForceUnixPaths(this->GlobalGenerator->GetForceUnixPaths());
 
   // Save the environment variables CXX and CC
-  const char* cxx = getenv("CXX");
-  const char* cc = getenv("CC");
-  if (cxx) {
-    this->CXXEnvironment = cxx;
-  } else {
+  if (!cmSystemTools::GetEnv("CXX", this->CXXEnvironment)) {
     this->CXXEnvironment = "";
   }
-  if (cc) {
-    this->CCEnvironment = cc;
-  } else {
+  if (!cmSystemTools::GetEnv("CC", this->CCEnvironment)) {
     this->CCEnvironment = "";
   }
 }
@@ -1429,7 +1424,7 @@ int cmake::Run(const std::vector<std::string>& args, bool noconfigure)
   // should fail (if "-i" is an option).  We cannot simply test
   // whether "-i" is given and remove it because some make programs
   // encode the MAKEFLAGS variable in a strange way.
-  if (getenv("MAKEFLAGS")) {
+  if (cmSystemTools::HasEnv("MAKEFLAGS")) {
     cmSystemTools::PutEnv("MAKEFLAGS=");
   }
 
@@ -1704,12 +1699,8 @@ void cmake::UpdateConversionPathTable()
 
 int cmake::CheckBuildSystem()
 {
-  // We do not need to rerun CMake.  Check dependency integrity.  Use
-  // the make system's VERBOSE environment variable to enable verbose
-  // output. This can be skipped by setting CMAKE_NO_VERBOSE (which is set
-  // by the Eclipse and KDevelop generators).
-  bool verbose = ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-                  (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+  // We do not need to rerun CMake.  Check dependency integrity.
+  const bool verbose = isCMakeVerbose();
 
   // This method will check the integrity of the build system if the
   // option was given on the command line.  It reads the given file to
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 010a3b2..8025d9b 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -17,6 +17,7 @@
 #include "cmMakefile.h"
 #include "cmQtAutoGenerators.h"
 #include "cmVersion.h"
+#include "cmUtils.hxx"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmDependsFortran.h" // For -E cmake_copy_f90_mod callback.
@@ -697,12 +698,7 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
 
     // Internal CMake dependency scanning support.
     else if (args[1] == "cmake_depends" && args.size() >= 6) {
-      // Use the make system's VERBOSE environment variable to enable
-      // verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
-      // (which is set by the Eclipse and KDevelop generators).
-      bool verbose =
-        ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-         (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+      const bool verbose = isCMakeVerbose();
 
       // Create a cmake object instance to process dependencies.
       cmake cm;
@@ -900,9 +896,9 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
         // 1/10th of a second after the untar.  If CMAKE_UNTAR_DELAY
         // is set in the env, its value will be used instead of 100.
         int delay = 100;
-        const char* delayVar = cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY");
-        if (delayVar) {
-          delay = atoi(delayVar);
+        std::string delayVar;
+        if (cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY", delayVar)) {
+          delay = atoi(delayVar.c_str());
         }
         if (delay) {
           cmSystemTools::Delay(delay);
@@ -1254,7 +1250,7 @@ int cmcmd::VisualStudioLink(std::vector<std::string>& args, int type)
   if (args.size() < 2) {
     return -1;
   }
-  bool verbose = cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR;
+  const bool verbose = cmSystemTools::HasEnv("VERBOSE");
   std::vector<std::string> expandedArgs;
   for (std::vector<std::string>::iterator i = args.begin(); i != args.end();
        ++i) {
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 81fb2f9..1af7bdb 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType;
 # define USE_CPUID 0
 #endif
 
+#include <cmsys/SystemTools.hxx>
+
 #if USE_CPUID
 
 #define CPUID_AWARE_COMPILER
@@ -3476,10 +3478,10 @@ SystemInformationImplementation::GetHostMemoryAvailable(const char *hostLimitEnv
   // apply a limit across a set of processes. Units are in KiB.
   if (hostLimitEnvVarName)
     {
-    const char *hostLimitEnvVarValue=getenv(hostLimitEnvVarName);
-    if (hostLimitEnvVarValue)
+    std::string hostLimitEnvVarValue;
+    if (SystemTools::GetEnv(hostLimitEnvVarName, hostLimitEnvVarValue))
       {
-      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue);
+      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue.c_str());
       if (hostLimit>0)
         {
         memTotal=min(hostLimit,memTotal);
@@ -3506,10 +3508,10 @@ SystemInformationImplementation::GetProcMemoryAvailable(
   // are not employed. Units are in KiB.
   if (procLimitEnvVarName)
     {
-    const char *procLimitEnvVarValue=getenv(procLimitEnvVarName);
-    if (procLimitEnvVarValue)
+    std::string procLimitEnvVarValue;
+    if (SystemTools::GetEnv(procLimitEnvVarName, procLimitEnvVarValue))
       {
-      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue);
+      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue.c_str());
       if (procLimit>0)
         {
         memAvail=min(procLimit,memAvail);
@@ -5408,11 +5410,7 @@ bool SystemInformationImplementation::QueryOSInformation()
     }
   this->Hostname = name;
 
-  const char* arch = getenv("PROCESSOR_ARCHITECTURE");
-  if(arch)
-    {
-    this->OSPlatform = arch;
-    }
+  SystemTools::GetEnv("PROCESSOR_ARCHITECTURE", this->OSPlatform);
 
 #else
 
diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index 2b1db4d..ace5126 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -421,14 +421,12 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
     {
     env = "PATH";
     }
-  const char* cpathEnv = SystemTools::GetEnv(env);
-  if ( !cpathEnv )
+  std::string pathEnv;
+  if ( !SystemTools::GetEnv(env, pathEnv) )
     {
     return;
     }
 
-  std::string pathEnv = cpathEnv;
-
   // A hack to make the below algorithm work.
   if(!pathEnv.empty() && *pathEnv.rbegin() != pathSep)
     {
@@ -2082,8 +2080,8 @@ void SystemTools::ConvertToUnixSlashes(std::string& path)
     pathCString = path.c_str();
     if(pathCString[0] == '~' && (pathCString[1] == '/' || pathCString[1] == '\0'))
       {
-      const char* homeEnv = SystemTools::GetEnv("HOME");
-      if (homeEnv)
+      std::string homeEnv;
+      if (SystemTools::GetEnv("HOME", homeEnv))
         {
         path.replace(0,1,homeEnv);
         }
@@ -4099,16 +4097,9 @@ void SystemTools::SplitPath(const std::string& p,
     if(root.size() == 1)
       {
 #if defined(_WIN32) && !defined(__CYGWIN__)
-      if(const char* userp = getenv("USERPROFILE"))
-        {
-        homedir = userp;
-        }
-      else
+      if (!SystemTools::GetEnv("USERPROFILE", homedir))
 #endif
-      if(const char* h = getenv("HOME"))
-        {
-        homedir = h;
-        }
+      SystemTools::GetEnv("HOME", homedir);
       }
 #ifdef HAVE_GETPWNAM
     else if(passwd* pw = getpwnam(root.c_str()+1))
@@ -4849,7 +4840,7 @@ int SystemTools::GetTerminalWidth()
   int width = -1;
 #ifdef HAVE_TTY_INFO
   struct winsize ws;
-  char *columns; /* Unix98 environment variable */
+  std::string columns; /* Unix98 environment variable */
   if(ioctl(1, TIOCGWINSZ, &ws) != -1 && ws.ws_col>0 && ws.ws_row>0)
     {
     width = ws.ws_col;
@@ -4858,12 +4849,11 @@ int SystemTools::GetTerminalWidth()
     {
     width = -1;
     }
-  columns = getenv("COLUMNS");
-  if(columns && *columns)
+  if(SystemTools::GetEnv("COLUMNS", columns) && !columns.empty())
     {
     long t;
     char *endptr;
-    t = strtol(columns, &endptr, 0);
+    t = strtol(columns.c_str(), &endptr, 0);
     if(endptr && !*endptr && (t>0) && (t<1000))
       {
       width = static_cast<int>(t);
@@ -5473,7 +5463,8 @@ void SystemTools::ClassInitialize()
 
   // If the current working directory is a logical path then keep the
   // logical name.
-  if(const char* pwd = getenv("PWD"))
+  std::string pwd_str;
+  if(SystemTools::GetEnv("PWD", pwd_str))
     {
     char buf[2048];
     if(const char* cwd = Getcwd(buf, 2048))
@@ -5485,10 +5476,9 @@ void SystemTools::ClassInitialize()
       std::string pwd_changed;
 
       // Test progressively shorter logical-to-physical mappings.
-      std::string pwd_str = pwd;
       std::string cwd_str = cwd;
       std::string pwd_path;
-      Realpath(pwd, pwd_path);
+      Realpath(pwd_str.c_str(), pwd_path);
       while(cwd_str == pwd_path && cwd_str != pwd_str)
         {
         // The current pair of paths is a working logical mapping.
@@ -5543,8 +5533,8 @@ static int SystemToolsDebugReport(int, char* message, int*)
 
 void SystemTools::EnableMSVCDebugHook()
 {
-  if (getenv("DART_TEST_FROM_DART") ||
-      getenv("DASHBOARD_TEST_FROM_CTEST"))
+  if (SystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      SystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST"))
     {
     _CrtSetReportHook(SystemToolsDebugReport);
     }
diff --git a/Source/kwsys/testSystemTools.cxx b/Source/kwsys/testSystemTools.cxx
index 4d97688..4dab347 100644
--- a/Source/kwsys/testSystemTools.cxx
+++ b/Source/kwsys/testSystemTools.cxx
@@ -848,9 +848,9 @@ static bool CheckPutEnv(const std::string& env, const char* name, const char* va
                     << "\") failed!" << std::endl;
     return false;
     }
-  const char* v = kwsys::SystemTools::GetEnv(name);
-  v = v? v : "(null)";
-  if(strcmp(v, value) != 0)
+  std::string v = "(null)";
+  kwsys::SystemTools::GetEnv(name, v);
+  if(v != value)
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not \"" << value << "\"!" << std::endl;
@@ -867,7 +867,8 @@ static bool CheckUnPutEnv(const char* env, const char* name)
                     << std::endl;
     return false;
     }
-  if(const char* v = kwsys::SystemTools::GetEnv(name))
+  std::string v;
+  if(kwsys::SystemTools::GetEnv(name, v))
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not (null)!" << std::endl;
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:12 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:12 +0300
Subject: [cmake-developers] [PATCH v3 6/7] Use Windows version of
	Directory::Load for MinGW too
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-6-davispuh@gmail.com>

Otherwise it would use POSIX functions which works only for ASCII paths.
---
 Source/kwsys/Directory.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx
index c549792..659c559 100644
--- a/Source/kwsys/Directory.cxx
+++ b/Source/kwsys/Directory.cxx
@@ -86,7 +86,7 @@ void Directory::Clear()
 
 // First microsoft compilers
 
-#if defined(_MSC_VER) || defined(__WATCOMC__)
+#if defined(_WIN32) || defined(__WATCOMC__)
 #include <windows.h>
 #include <io.h>
 #include <ctype.h>
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:11 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:11 +0300
Subject: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows
	use our own std::streambuf
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-5-davispuh@gmail.com>

Currently Microsoft's C++ libraries implementation of std::cout/cerr
can't output Unicode characters but only ASCII or ANSI if locale is set
so we implement and use our own ConsoleBuf which can output Unicode
characters to console and it doesn't matter what locale or console's
codepage is set.
---
 CMakeLists.txt                 |   1 +
 Source/cmakemain.cxx           |  28 +++++++++
 Source/kwsys/CMakeLists.txt    |   6 +-
 Source/kwsys/ConsoleBuf.hxx.in | 131 +++++++++++++++++++++++++++++++++++++++++
 bootstrap                      |   1 +
 5 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 Source/kwsys/ConsoleBuf.hxx.in

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ae5990e..792b5a5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -258,6 +258,7 @@ macro (CMAKE_BUILD_UTILITIES)
   set(KWSYS_USE_MD5 1)
   set(KWSYS_USE_Process 1)
   set(KWSYS_USE_CommandLineArguments 1)
+  set(KWSYS_USE_ConsoleBuf 1)
   set(KWSYS_HEADER_ROOT ${CMake_BINARY_DIR}/Source)
   set(KWSYS_INSTALL_DOC_DIR "${CMAKE_DOC_DIR}")
   add_subdirectory(Source/kwsys)
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index 521a5bf..2002e4b 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -26,6 +26,7 @@
 #include "cmake.h"
 #include "cmcmd.h"
 #include <cmsys/Encoding.hxx>
+#include <cmsys/ConsoleBuf.hxx>
 
 #ifdef CMAKE_BUILD_WITH_CMAKE
 static const char* cmDocumentationName[][2] = {
@@ -153,6 +154,23 @@ static void cmakemainProgressCallback(const char* m, float prog,
 
 int main(int ac, char const* const* av)
 {
+#if defined(_WIN32)
+  // Replace streambuf so we can output Unicode to console
+  cmsys::ConsoleBuf *cbufio = CM_NULLPTR;
+  cmsys::ConsoleBuf *cbuferr = CM_NULLPTR;
+  std::streambuf *coutbuf = CM_NULLPTR;
+  std::streambuf *cerrbuf = CM_NULLPTR;
+  try {
+    cbufio = new cmsys::ConsoleBuf();
+    coutbuf = std::cout.rdbuf(cbufio);
+    cbuferr = new cmsys::ConsoleBuf(true);
+    cerrbuf = std::cerr.rdbuf(cbuferr);
+  } catch (const std::system_error& ex) {
+    std::cerr << "Failed to create ConsoleBuf!" << std::endl
+              << "Error code: " << ex.code() << std::endl
+              << ex.what() << std::endl;
+  };
+#endif
   cmsys::Encoding::CommandLineArguments args =
     cmsys::Encoding::CommandLineArguments::Main(ac, av);
   ac = args.argc();
@@ -171,6 +189,16 @@ int main(int ac, char const* const* av)
 #ifdef CMAKE_BUILD_WITH_CMAKE
   cmDynamicLoader::FlushCache();
 #endif
+#if defined(_WIN32)
+  if (cbufio) {
+    delete cbufio;
+    std::cout.rdbuf(coutbuf);
+  }
+  if (cbuferr) {
+    delete cbuferr;
+    std::cerr.rdbuf(cerrbuf);
+  }
+#endif
   return ret;
 }
 
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 65203c0..33a97e6 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -123,6 +123,7 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
   SET(KWSYS_USE_FStream 1)
   SET(KWSYS_USE_String 1)
   SET(KWSYS_USE_SystemInformation 1)
+  SET(KWSYS_USE_ConsoleBuf 1)
 ENDIF()
 
 # Enforce component dependencies.
@@ -154,6 +155,9 @@ ENDIF()
 IF(KWSYS_USE_FStream)
   SET(KWSYS_USE_Encoding 1)
 ENDIF()
+IF(KWSYS_USE_ConsoleBuf)
+  SET(KWSYS_USE_Encoding 1)
+ENDIF()
 
 # Setup the large file support default.
 IF(KWSYS_LFS_DISABLE)
@@ -668,7 +672,7 @@ SET(KWSYS_HXX_FILES Configure String
 # Add selected C++ classes.
 SET(cppclasses
   Directory DynamicLoader Encoding Glob RegularExpression SystemTools
-  CommandLineArguments IOStream FStream SystemInformation
+  CommandLineArguments IOStream FStream SystemInformation ConsoleBuf
   )
 FOREACH(cpp ${cppclasses})
   IF(KWSYS_USE_${cpp})
diff --git a/Source/kwsys/ConsoleBuf.hxx.in b/Source/kwsys/ConsoleBuf.hxx.in
new file mode 100644
index 0000000..90adc03
--- /dev/null
+++ b/Source/kwsys/ConsoleBuf.hxx.in
@@ -0,0 +1,131 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+#define @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+
+#include <@KWSYS_NAMESPACE@/Configure.hxx>
+#include <@KWSYS_NAMESPACE@/Encoding.hxx>
+#include <streambuf>
+
+namespace @KWSYS_NAMESPACE@
+{
+#if defined(_WIN32)
+
+  template<class CharT, class Traits = std::char_traits<CharT>>
+  class @KWSYS_NAMESPACE at _EXPORT BasicConsoleBuf : public std::basic_streambuf<CharT, Traits> {
+    public:
+      typedef typename Traits::int_type int_type;
+      typedef typename Traits::char_type char_type;
+
+      BasicConsoleBuf(const bool err = false) {
+        m_hInput = ::GetStdHandle(STD_INPUT_HANDLE);
+        if (m_hInput == INVALID_HANDLE_VALUE) {
+          throw std::system_error(::GetLastError(), std::system_category(), "GetStdHandle(STD_INPUT_HANDLE) returned INVALID_HANDLE_VALUE");
+        }
+        if (err) {
+          m_hOutput = ::GetStdHandle(STD_ERROR_HANDLE);
+        } else {
+          m_hOutput = ::GetStdHandle(STD_OUTPUT_HANDLE);
+        }
+        if (m_hOutput == INVALID_HANDLE_VALUE) {
+          throw std::system_error(::GetLastError(), std::system_category(),
+                                  std::string("GetStdHandle(") + (err ? "STD_ERROR_HANDLE" : "STD_OUTPUT_HANDLE") + ") returned INVALID_HANDLE_VALUE");
+        }
+        this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
+      }
+
+      ~BasicConsoleBuf() {
+        sync();
+      }
+
+    protected:
+      virtual int sync() {
+        bool success = true;
+        if (m_hInput) {
+          if (::FlushConsoleInputBuffer(m_hInput) == 0) {
+            success = false;
+          }
+        }
+        if (m_hOutput && !m_obuffer.empty()) {
+          const std::wstring &wBuffer = getBuffer(m_obuffer);
+          DWORD charsWritten;
+          if (::WriteConsoleW(m_hOutput, wBuffer.c_str(), (DWORD)wBuffer.size(), &charsWritten, NULL) == 0) {
+            success = false;
+          }
+        }
+        m_ibuffer.clear();
+        m_obuffer.clear();
+        this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
+        return success ? 0 : -1;
+      }
+
+      virtual int_type underflow() {
+        if (this->gptr() >= this->egptr()) {
+          wchar_t wBuffer[128];
+          DWORD charsRead;
+          if (!m_hInput || ::ReadConsoleW(m_hInput, wBuffer, ARRAYSIZE(wBuffer) - 1, &charsRead, NULL) == 0 || charsRead == 0) {
+            this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+            return Traits::eof();
+          }
+          wBuffer[charsRead] = L'\0';
+          setBuffer(wBuffer, m_ibuffer);
+          this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        }
+        return Traits::to_int_type(*this->gptr());
+      }
+
+      virtual int_type overflow(int_type ch = Traits::eof()) {
+        if (!Traits::eq_int_type(ch, Traits::eof())) {
+          char_type chr = Traits::to_char_type(ch);
+          m_obuffer += chr;
+          if ((flush_on_newline && Traits::eq(chr, '\n')) || Traits::eq_int_type(ch, 0x00)) {
+            sync();
+          }
+          return ch;
+        }
+        sync();
+        return Traits::eof();
+      }
+
+    public:
+      bool flush_on_newline = true;
+
+    private:
+      HANDLE m_hInput = NULL;
+      HANDLE m_hOutput = NULL;
+      std::basic_string<char_type> m_ibuffer;
+      std::basic_string<char_type> m_obuffer;
+      const std::wstring getBuffer(const std::basic_string<char> buffer) {
+        return Encoding::ToWide(buffer);
+      }
+      const std::wstring &getBuffer(const std::basic_string<wchar_t> &buffer) {
+        return buffer;
+      }
+      void setBuffer(const wchar_t buffer[], std::basic_string<char> &target) {
+        target = Encoding::ToNarrow(buffer);
+      }
+      void setBuffer(const wchar_t buffer[], std::basic_string<wchar_t> &target) {
+        target = buffer;
+      }
+
+  }; // BasicConsoleBuf class
+
+  typedef BasicConsoleBuf<char>    ConsoleBuf;
+  typedef BasicConsoleBuf<wchar_t> WConsoleBuf;
+
+#endif
+} // KWSYS_NAMESPACE
+
+#endif
+
diff --git a/bootstrap b/bootstrap
index ad0c8ec..0411c64 100755
--- a/bootstrap
+++ b/bootstrap
@@ -365,6 +365,7 @@ KWSYS_CXX_SOURCES="\
   SystemTools"
 
 KWSYS_FILES="\
+  ConsoleBuf.hxx \
   Directory.hxx \
   Encoding.h \
   Encoding.hxx \
-- 
2.9.0


From davispuh at gmail.com  Wed Jul  6 15:12:13 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed,  6 Jul 2016 22:12:13 +0300
Subject: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream
In-Reply-To: <20160706191213.16242-1-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
Message-ID: <20160706191213.16242-7-davispuh@gmail.com>

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard
and it's only present for MSVC but it's not present in libstdc++ (MinGW)
so we implement this functionality using GNU stdio_filebuf extension and
_wfopen function.
---
 Source/kwsys/FStream.hxx.in | 117 +++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 109 insertions(+), 8 deletions(-)

diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in
index 681e4d8..f39f95a 100644
--- a/Source/kwsys/FStream.hxx.in
+++ b/Source/kwsys/FStream.hxx.in
@@ -14,33 +14,76 @@
 
 #include <@KWSYS_NAMESPACE@/Encoding.hxx>
 #include <fstream>
+#if defined(_WIN32) && !defined(_MSC_VER)
+#include <ext/stdio_filebuf.h>
+#endif
 
 namespace @KWSYS_NAMESPACE@
 {
-#if defined(_MSC_VER) && _MSC_VER >= 1400
+#if defined(_WIN32)
 # if defined(_NOEXCEPT)
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT _NOEXCEPT
 # else
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT
 # endif
+
+#if defined(_MSC_VER)
+
   template<typename CharType,typename Traits>
   class basic_filebuf : public std::basic_filebuf<CharType,Traits>
   {
+# if _MSC_VER >= 1400
     public:
       typedef std::basic_filebuf<CharType,Traits> my_base_type;
       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
       {
+        const std::wstring wstr = Encoding::ToWide(s);
         return static_cast<basic_filebuf*>(
-          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
+          my_base_type::open(wstr.c_str(), mode)
           );
       }
+# else
+#  pragma message("Warning! Opening non-ASCII files might fail!")
+# endif
+
   };
 
+#else
+
+  inline const std::wstring getcmode(const std::ios_base::openmode mode) {
+    std::wstring cmode;
+    bool plus = false;
+    if (mode & std::ios_base::app) {
+      cmode += L"a";
+      plus = mode & std::ios_base::in ? true : false;
+    } else if (mode & std::ios_base::trunc || mode & std::ios_base::out) {
+      cmode += L"w";
+      plus = mode & std::ios_base::in ? true : false;
+    } else {
+      cmode += L"r";
+    }
+    if (mode & std::ios_base::binary) {
+      cmode += L"b";
+    } else {
+      cmode += L"t";
+    }
+    if (plus) {
+      cmode += L"+";
+    }
+    return cmode;
+  };
+
+#endif
+
   template<typename CharType,typename Traits = std::char_traits<CharType> >
   class basic_ifstream : public std::basic_istream<CharType,Traits>
   {
   public:
+#if defined(_MSC_VER)
     typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+#else
+    typedef __gnu_cxx::stdio_filebuf<CharType,Traits> internal_buffer_type;
+#endif
     typedef std::basic_istream<CharType,Traits> internal_stream_type;
 
     basic_ifstream() : internal_stream_type(new internal_buffer_type())
@@ -56,7 +99,24 @@ namespace @KWSYS_NAMESPACE@
     }
     void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
     {
-      if(!buf_->open(file_name,mode | std::ios_base::in))
+      mode = mode | std::ios_base::in;
+#if defined(_MSC_VER)
+      const bool success = buf_->open(file_name,mode) != 0;
+#else
+      const std::wstring wstr = Encoding::ToWide(file_name);
+      bool success = false;
+      std::wstring cmode = getcmode(mode);
+      file_ = _wfopen(wstr.c_str(), cmode.c_str());
+      if (file_) {
+        if (buf_) {
+          delete buf_;
+        }
+        buf_ = new internal_buffer_type(file_, mode);
+        this->set_rdbuf(buf_);
+        success = true;
+      }
+#endif
+      if(!success)
         {
         this->setstate(std::ios_base::failbit);
         }
@@ -75,7 +135,14 @@ namespace @KWSYS_NAMESPACE@
     }
     void close()
     {
-      if(!buf_->close())
+      bool success = buf_->close() != 0;
+#if !defined(_MSC_VER)
+      if (file_) {
+        success = fclose(file_) == 0 ? success : false;
+        file_ = 0;
+      }
+#endif
+      if(!success)
         {
         this->setstate(std::ios_base::failbit);
         }
@@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
 
     ~basic_ifstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
     {
-      buf_->close();
+      close();
       delete buf_;
     }
 
   private:
     internal_buffer_type* buf_;
+#if !defined(_MSC_VER)
+    FILE *file_ = 0;
+#endif
 };
 
 template<typename CharType,typename Traits = std::char_traits<CharType> >
 class basic_ofstream : public std::basic_ostream<CharType,Traits>
 {
   public:
+#if defined(_MSC_VER)
   typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+#else
+  typedef __gnu_cxx::stdio_filebuf<CharType,Traits> internal_buffer_type;
+#endif
   typedef std::basic_ostream<CharType,Traits> internal_stream_type;
 
   basic_ofstream() : internal_stream_type(new internal_buffer_type())
@@ -119,7 +193,24 @@ class basic_ofstream : public std::basic_ostream<CharType,Traits>
   }
   void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::out)
   {
-    if(!buf_->open(file_name,mode | std::ios_base::out))
+    mode = mode | std::ios_base::out;
+#if defined(_MSC_VER)
+    const bool success = buf_->open(file_name,mode) != 0;
+#else
+    const std::wstring wstr = Encoding::ToWide(file_name);
+    bool success = false;
+    std::wstring cmode = getcmode(mode);
+    file_ = _wfopen(wstr.c_str(), cmode.c_str());
+    if (file_) {
+      if (buf_) {
+        delete buf_;
+      }
+      buf_ = new internal_buffer_type(file_, mode);
+      this->set_rdbuf(buf_);
+      success = true;
+    }
+#endif
+    if(!success)
     {
     this->setstate(std::ios_base::failbit);
     }
@@ -138,7 +229,14 @@ class basic_ofstream : public std::basic_ostream<CharType,Traits>
   }
   void close()
   {
-    if(!buf_->close())
+    bool success = buf_->close() != 0;
+#if !defined(_MSC_VER)
+    if (file_) {
+      success = fclose(file_) == 0 ? success : false;
+      file_ = 0;
+    }
+#endif
+    if(!success)
       {
       this->setstate(std::ios_base::failbit);
       }
@@ -154,12 +252,15 @@ class basic_ofstream : public std::basic_ostream<CharType,Traits>
   }
   ~basic_ofstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
   {
-    buf_->close();
+    close();
     delete buf_;
   }
 
   private:
   internal_buffer_type* buf_;
+#if !defined(_MSC_VER)
+    FILE *file_ = 0;
+#endif
 };
 
   typedef basic_ifstream<char> ifstream;
-- 
2.9.0


From mikedld at mikedld.com  Wed Jul  6 17:39:06 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 7 Jul 2016 00:39:06 +0300
Subject: [cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and
 HasEnv functions
In-Reply-To: <20160706191213.16242-3-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-3-davispuh@gmail.com>
Message-ID: <f8b741eb-b425-7201-4da2-a98bdefe6859@mikedld.com>

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 <cmsys/SystemTools.hxx>
> +
>  #if USE_CPUID
>  
>  #define CPUID_AWARE_COMPILER
IIUC, in kwsys/ subdirectory it should be `#include
KWSYS_HEADER(SystemTools.hxx)` instead, with corresponding `#include
"SystemTools.hxx.in"` inside `#if 0 ... #endif` block.

Regards,
Mike

From clinton at elemtech.com  Wed Jul  6 17:42:28 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Wed, 06 Jul 2016 15:42:28 -0600
Subject: [cmake-developers] [PATCH v3 5/7] For consoles output on
 Windows	use our own std::streambuf
In-Reply-To: <20160706191213.16242-5-davispuh@gmail.com>
Message-ID: <d4697015-6acc-4e9c-95d9-1b1a0d887169@email.android.com>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160706/8f348b93/attachment-0001.html>

From mikedld at mikedld.com  Wed Jul  6 18:22:06 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 7 Jul 2016 01:22:06 +0300
Subject: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream
In-Reply-To: <20160706191213.16242-7-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-7-davispuh@gmail.com>
Message-ID: <2da03bd6-3d4d-debf-8d78-f85ae9523969@mikedld.com>

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 <fstream>
> +#if defined(_WIN32) && !defined(_MSC_VER)
> +#include <ext/stdio_filebuf.h>
> +#endif
>  
>  namespace @KWSYS_NAMESPACE@
>  {
AFAIK, libc++ doesn't have this header, but only libstdc++ does. Not
sure if Clang on Windows defines _MSC_VER (the one included with recent
MSVS versions might, but standalone one is another story), might be
better to check for HAVE_EXT_STDIO_FILEBUF_H macro instead (or in
addition), to be defined externally on configuration phase. Same goes
for a few checks down in the same file.

> +  inline const std::wstring getcmode(const std::ios_base::openmode mode) {
Const on return value makes no sense. Some compilers may even warn about it.

> @@ -56,7 +99,24 @@ namespace @KWSYS_NAMESPACE@
>      }
>      void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
>      {
> -      if(!buf_->open(file_name,mode | std::ios_base::in))
> +      mode = mode | std::ios_base::in;
> +#if defined(_MSC_VER)
> +      const bool success = buf_->open(file_name,mode) != 0;
> +#else
> +      const std::wstring wstr = Encoding::ToWide(file_name);
> +      bool success = false;
> +      std::wstring cmode = getcmode(mode);
> +      file_ = _wfopen(wstr.c_str(), cmode.c_str());
> +      if (file_) {
> +        if (buf_) {
> +          delete buf_;
> +        }
> +        buf_ = new internal_buffer_type(file_, mode);
> +        this->set_rdbuf(buf_);
> +        success = true;
> +      }
> +#endif
> +      if(!success)
>          {
>          this->setstate(std::ios_base::failbit);
>          }
Looks odd that you check whether `buf_` is set before assigning, but
don't check if `file_` is. Either one check is missing or another is
redundant; the former is more probable since per STL documentation (e.g.
http://www.cplusplus.com/reference/fstream/fstream/open/), "If the
stream is already associated with a file (i.e., it is already open),
calling this function fails."

> @@ -75,7 +135,14 @@ namespace @KWSYS_NAMESPACE@
>      }
>      void close()
>      {
> -      if(!buf_->close())
> +      bool success = buf_->close() != 0;
> +#if !defined(_MSC_VER)
> +      if (file_) {
> +        success = fclose(file_) == 0 ? success : false;
> +        file_ = 0;
> +      }
> +#endif
> +      if(!success)
>          {
>          this->setstate(std::ios_base::failbit);
>          }
`success` is overwritten inside newly added condition w/o checking
previous value; looks odd as well.

> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
> [snip] 
>    private:
>      internal_buffer_type* buf_;
> +#if !defined(_MSC_VER)
> +    FILE *file_ = 0;
> +#endif
>  };
>  
>  template<typename CharType,typename Traits = std::char_traits<CharType> >
In-place member initialization... As Brad wrote earlier, using C++11 in
KWSys is not advised.

> @@ -119,7 +193,24 @@ class basic_ofstream : public std::basic_ostream<CharType,Traits>
>    }
>    void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::out)
>    {
> -    if(!buf_->open(file_name,mode | std::ios_base::out))
> +    mode = mode | std::ios_base::out;
> +#if defined(_MSC_VER)
> +    const bool success = buf_->open(file_name,mode) != 0;
> +#else
> +    const std::wstring wstr = Encoding::ToWide(file_name);
> +    bool success = false;
> +    std::wstring cmode = getcmode(mode);
> +    file_ = _wfopen(wstr.c_str(), cmode.c_str());
> +    if (file_) {
> +      if (buf_) {
> +        delete buf_;
> +      }
> +      buf_ = new internal_buffer_type(file_, mode);
> +      this->set_rdbuf(buf_);
> +      success = true;
> +    }
> +#endif
> +    if(!success)
>      {
>      this->setstate(std::ios_base::failbit);
>      }
Mostly duplicate from istream, consider factoring out in some way.

Regards,
Mike

From mikedld at mikedld.com  Wed Jul  6 18:36:02 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 7 Jul 2016 01:36:02 +0300
Subject: [cmake-developers] [PATCH v3 5/7] For consoles output on
 Windows use our own std::streambuf
In-Reply-To: <d4697015-6acc-4e9c-95d9-1b1a0d887169@email.android.com>
References: <d4697015-6acc-4e9c-95d9-1b1a0d887169@email.android.com>
Message-ID: <03260d88-bc38-ce85-27e4-350c011c5b53@mikedld.com>

On 07/07/2016 12:42 AM, clinton at 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 whether
corresponding stream is linked to terminal or not. Replacing stream
buffers unconditionally is not right.

Regards,
Mike

From mikedld at mikedld.com  Wed Jul  6 19:21:31 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 7 Jul 2016 02:21:31 +0300
Subject: [cmake-developers] [PATCH v3 5/7] For consoles output on
 Windows use our own std::streambuf
In-Reply-To: <20160706191213.16242-5-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-5-davispuh@gmail.com>
Message-ID: <7e9d3ead-3f18-465a-5894-013107d7defc@mikedld.com>

Just a small nore: as I failed to mention this before, the approach
taken in this patch will lead to messages to be printed to stdout and
stderr in CMake's internal encoding (UTF-8?) when ConsoleBuf is not
used, i.e. 1) on non-Windows and 2) on Windows with one or another
stream redirected to file/pipe (considering corresponding check is in
place). Seems to be the case anyway now, but maybe something to think about.

On 07/06/2016 10:12 PM, D?vis Mos?ns wrote:
> --- a/Source/cmakemain.cxx
> +++ b/Source/cmakemain.cxx
> @@ -171,6 +189,16 @@ int main(int ac, char const* const* av)
>  #ifdef CMAKE_BUILD_WITH_CMAKE
>    cmDynamicLoader::FlushCache();
>  #endif
> +#if defined(_WIN32)
> +  if (cbufio) {
> +    delete cbufio;
> +    std::cout.rdbuf(coutbuf);
> +  }
> +  if (cbuferr) {
> +    delete cbuferr;
> +    std::cerr.rdbuf(cerrbuf);
> +  }
> +#endif
>    return ret;
>  }
>  
If exception was thrown in the beginning of main (as it seems you expect
one there), `coutbuf` and/or `cerrbuf` could be nullptr, and passing
nullptr here will fail.

> +  template<class CharT, class Traits = std::char_traits<CharT>>
C++11 in KWSys here as well (>> at the end of line is a single token in
pre-C++11)...

> +          throw std::system_error(::GetLastError(), std::system_category(), "GetStdHandle([snip]) returned INVALID_HANDLE_VALUE");
... and here (no std::system_error in pre-C++11)... and other places
further.

> +          m_hOutput = ::GetStdHandle(STD_ERROR_HANDLE);
Using WinAPI but missing corresponding system #include.

> [snip]
> +      virtual int sync() {
> [snip]
> +          const std::wstring &wBuffer = getBuffer(m_obuffer);
> [snip]
There are two `getBuffer`, one returning by value (for narrow char type)
and another by reference (for wide char type). When first one is in
effect, assigning the result to reference variable seems to be
guaranteed to work by the standard (at least I remember reading
something about it), but in reality it works in some cases and fails
(e.g. segfaults) in other, depending on compiler and flags.

> +        this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
> +        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
This pattern over and over again. Needs to be put into separate member
function, otherwise some day someone will mix "i" and "o" and wonder why
doesn't it work.

Also, I don't see that many calls to set(g|p) in that SO snipped, are
they all really needed?

Regards,
Mike

From davispuh at gmail.com  Wed Jul  6 20:33:11 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Thu, 7 Jul 2016 03:33:11 +0300
Subject: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream
In-Reply-To: <2da03bd6-3d4d-debf-8d78-f85ae9523969@mikedld.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-7-davispuh@gmail.com>
 <2da03bd6-3d4d-debf-8d78-f85ae9523969@mikedld.com>
Message-ID: <CAOE4rSyt72tp1_afEzcLRdDkURukAy9wtTyZo7Qd0cS=Cq++1A@mail.gmail.com>

2016-07-07 1:22 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
>
> 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 <fstream>
> > +#if defined(_WIN32) && !defined(_MSC_VER)
> > +#include <ext/stdio_filebuf.h>
> > +#endif
> >
> >  namespace @KWSYS_NAMESPACE@
> >  {
> AFAIK, libc++ doesn't have this header, but only libstdc++ does. Not
> sure if Clang on Windows defines _MSC_VER (the one included with recent
> MSVS versions might, but standalone one is another story), might be
> better to check for HAVE_EXT_STDIO_FILEBUF_H macro instead (or in
> addition), to be defined externally on configuration phase. Same goes
> for a few checks down in the same file.
>

I currently don't have other compilers besides MSVC (2015) and MinGW
(GCC 6.1.1) so I tested only on those. I don't know what Clang or Cygwin
would use.

> > @@ -56,7 +99,24 @@ namespace @KWSYS_NAMESPACE@
> >      }
> >      void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
> >      {
> > -      if(!buf_->open(file_name,mode | std::ios_base::in))
> > +      mode = mode | std::ios_base::in;
> > +#if defined(_MSC_VER)
> > +      const bool success = buf_->open(file_name,mode) != 0;
> > +#else
> > +      const std::wstring wstr = Encoding::ToWide(file_name);
> > +      bool success = false;
> > +      std::wstring cmode = getcmode(mode);
> > +      file_ = _wfopen(wstr.c_str(), cmode.c_str());
> > +      if (file_) {
> > +        if (buf_) {
> > +          delete buf_;
> > +        }
> > +        buf_ = new internal_buffer_type(file_, mode);
> > +        this->set_rdbuf(buf_);
> > +        success = true;
> > +      }
> > +#endif
> > +      if(!success)
> >          {
> >          this->setstate(std::ios_base::failbit);
> >          }
> Looks odd that you check whether `buf_` is set before assigning, but
> don't check if `file_` is. Either one check is missing or another is
> redundant; the former is more probable since per STL documentation (e.g.
> http://www.cplusplus.com/reference/fstream/fstream/open/), "If the
> stream is already associated with a file (i.e., it is already open),
> calling this function fails."

Indeed I forgot about case when stream is already open. Need to return
early from that. And yeah I guess can delete buf_ unconditionally.

>
> > @@ -75,7 +135,14 @@ namespace @KWSYS_NAMESPACE@
> >      }
> >      void close()
> >      {
> > -      if(!buf_->close())
> > +      bool success = buf_->close() != 0;
> > +#if !defined(_MSC_VER)
> > +      if (file_) {
> > +        success = fclose(file_) == 0 ? success : false;
> > +        file_ = 0;
> > +      }
> > +#endif
> > +      if(!success)
> >          {
> >          this->setstate(std::ios_base::failbit);
> >          }
> `success` is overwritten inside newly added condition w/o checking
> previous value; looks odd as well.
>

Look more carefully.

        success = fclose(file_) == 0 ? success : false;

We return success only if both buf_->close() and fclose(file_)
returned success. If any of them failed we return failure.

>
> > @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
> > [snip]
> >    private:
> >      internal_buffer_type* buf_;
> > +#if !defined(_MSC_VER)
> > +    FILE *file_ = 0;
> > +#endif
> >  };
> >
> >  template<typename CharType,typename Traits = std::char_traits<CharType> >
> In-place member initialization... As Brad wrote earlier, using C++11 in
> KWSys is not advised.
>

This was already there but only used for _MSC_VER >= 1400
Maybe could just guard this with  __cplusplus >= 201103L and not support
Unicode for older, it would be much easier...

From mikedld at mikedld.com  Wed Jul  6 20:51:19 2016
From: mikedld at mikedld.com (Mike Gelfand)
Date: Thu, 7 Jul 2016 03:51:19 +0300
Subject: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream
In-Reply-To: <CAOE4rSyt72tp1_afEzcLRdDkURukAy9wtTyZo7Qd0cS=Cq++1A@mail.gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-7-davispuh@gmail.com>
 <2da03bd6-3d4d-debf-8d78-f85ae9523969@mikedld.com>
 <CAOE4rSyt72tp1_afEzcLRdDkURukAy9wtTyZo7Qd0cS=Cq++1A@mail.gmail.com>
Message-ID: <71b639de-0fdc-ae18-f03a-a5816b2f390e@mikedld.com>

On 07/07/2016 03:33 AM, D?vis Mos?ns wrote:
> 2016-07-07 1:22 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
>>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
>>> [snip]
>>>    private:
>>>      internal_buffer_type* buf_;
>>> +#if !defined(_MSC_VER)
>>> +    FILE *file_ = 0;
>>> +#endif
>>>  };
>>>
>>>  template<typename CharType,typename Traits = std::char_traits<CharType> >
>> In-place member initialization... As Brad wrote earlier, using C++11 in
>> KWSys is not advised.
>>
> This was already there but only used for _MSC_VER >= 1400
> Maybe could just guard this with  __cplusplus >= 201103L and not support
> Unicode for older, it would be much easier...

Apologies, don't quite get your response. Maybe the quote was too big; I
surely meant to point to "FILE *file_ = 0;" line, not the template
declaration or something else.

Regards,
Mike

From davispuh at gmail.com  Wed Jul  6 21:27:20 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Thu, 7 Jul 2016 04:27:20 +0300
Subject: [cmake-developers] [PATCH v3 5/7] For consoles output on
 Windows use our own std::streambuf
In-Reply-To: <7e9d3ead-3f18-465a-5894-013107d7defc@mikedld.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-5-davispuh@gmail.com>
 <7e9d3ead-3f18-465a-5894-013107d7defc@mikedld.com>
Message-ID: <CAOE4rSwsLMUdnx8kg5zMxuzJzjojPq_GXnh_KJhZ-F8B_6wa=w@mail.gmail.com>

2016-07-07 1:36 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
> On 07/07/2016 12:42 AM, clinton at 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 whether
> corresponding stream is linked to terminal or not. Replacing stream
> buffers unconditionally is not right.
>

Sorry, I missed this... Will fix.

2016-07-07 2:21 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
> Just a small nore: as I failed to mention this before, the approach
> taken in this patch will lead to messages to be printed to stdout and
> stderr in CMake's internal encoding (UTF-8?) when ConsoleBuf is not
> used, i.e. 1) on non-Windows and 2) on Windows with one or another
> stream redirected to file/pipe (considering corresponding check is in
> place). Seems to be the case anyway now, but maybe something to think about.
>

I know this, it always have been the case and with this patch I fix only
output to console because currently it would output internal encoding
which is unreadable for non-ASCII because console expects different codepage.

As for encoding used for files it doesn't matter because we use same one
for both writing and reading. It would matter if other applications would
want to read it. And because it's set as UTF-8 it should work fine.

> On 07/06/2016 10:12 PM, D?vis Mos?ns wrote:
>> --- a/Source/cmakemain.cxx
>> +++ b/Source/cmakemain.cxx
>> @@ -171,6 +189,16 @@ int main(int ac, char const* const* av)
>>  #ifdef CMAKE_BUILD_WITH_CMAKE
>>    cmDynamicLoader::FlushCache();
>>  #endif
>> +#if defined(_WIN32)
>> +  if (cbufio) {
>> +    delete cbufio;
>> +    std::cout.rdbuf(coutbuf);
>> +  }
>> +  if (cbuferr) {
>> +    delete cbuferr;
>> +    std::cerr.rdbuf(cerrbuf);
>> +  }
>> +#endif
>>    return ret;
>>  }
>>
> If exception was thrown in the beginning of main (as it seems you expect
> one there), `coutbuf` and/or `cerrbuf` could be nullptr, and passing
> nullptr here will fail.

coutbuf can be null only if

    cbufio = new cmsys::ConsoleBuf();

threw an exception in which case cbufio will be null and so it won't be set
here. And same for cerrbuf, it will be set if cbuferr is set in which case it
means there weren't any exception. While I think it's not needed, I can
add check for it and set rdbuf only when not null.

>
>> +        this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
>> +        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
> This pattern over and over again. Needs to be put into separate member
> function, otherwise some day someone will mix "i" and "o" and wonder why
> doesn't it work.
>
> Also, I don't see that many calls to set(g|p) in that SO snipped, are
> they all really needed?
>

There aren't really that many calls, we set both once in constructor,
both once in sync and setg twice (differently) in underflow, because
two cases:

"The function may update gptr, egptr and eback pointers to define the
location of newly loaded data (if any). On failure, the function ensures
that either gptr() == nullptr or gptr() == egptr"

from http://en.cppreference.com/w/cpp/io/basic_streambuf/underflow

From davispuh at gmail.com  Wed Jul  6 21:30:47 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Thu, 7 Jul 2016 04:30:47 +0300
Subject: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream
In-Reply-To: <71b639de-0fdc-ae18-f03a-a5816b2f390e@mikedld.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-7-davispuh@gmail.com>
 <2da03bd6-3d4d-debf-8d78-f85ae9523969@mikedld.com>
 <CAOE4rSyt72tp1_afEzcLRdDkURukAy9wtTyZo7Qd0cS=Cq++1A@mail.gmail.com>
 <71b639de-0fdc-ae18-f03a-a5816b2f390e@mikedld.com>
Message-ID: <CAOE4rSwgjKqvnsJR2nzEw2Ax-dfOtqVGt==0KS0SYaM-Wh5BuA@mail.gmail.com>

2016-07-07 3:51 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
> On 07/07/2016 03:33 AM, D?vis Mos?ns wrote:
>> 2016-07-07 1:22 GMT+03:00 Mike Gelfand <mikedld at mikedld.com>:
>>>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
>>>> [snip]
>>>>    private:
>>>>      internal_buffer_type* buf_;
>>>> +#if !defined(_MSC_VER)
>>>> +    FILE *file_ = 0;
>>>> +#endif
>>>>  };
>>>>
>>>>  template<typename CharType,typename Traits = std::char_traits<CharType> >
>>> In-place member initialization... As Brad wrote earlier, using C++11 in
>>> KWSys is not advised.
>>>
>> This was already there but only used for _MSC_VER >= 1400
>> Maybe could just guard this with  __cplusplus >= 201103L and not support
>> Unicode for older, it would be much easier...
>
> Apologies, don't quite get your response. Maybe the quote was too big; I
> surely meant to point to "FILE *file_ = 0;" line, not the template
> declaration or something else.


Oh sorry, I misunderstood you earlier and yeah I see, will fix.

From konstantin at podsvirov.pro  Thu Jul  7 07:43:48 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 07 Jul 2016 14:43:48 +0300
Subject: [cmake-developers] [CpackIFW] Fix bug in cpack_ifw_configure_...
	commands
Message-ID: <769801467891828@web23o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160707/9785dfd9/attachment.html>

From brad.king at kitware.com  Thu Jul  7 08:44:35 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 7 Jul 2016 08:44:35 -0400
Subject: [cmake-developers] [CpackIFW] Fix bug in
	cpack_ifw_configure_... commands
In-Reply-To: <769801467891828@web23o.yandex.ru>
References: <769801467891828@web23o.yandex.ru>
Message-ID: <577E4EB3.9070500@kitware.com>

On 07/07/2016 07:43 AM, Konstantin Podsvirov wrote:
> Can you also merge topic 'cpack-ifw-list-variable' to release branch?

Does it fix a 3.6 regression or a bug in a 3.6 new feature?
Fixes to long-standing bugs are not eligible to be backported
to the release.

Thanks,
-Brad

From brad.king at kitware.com  Thu Jul  7 08:44:51 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 7 Jul 2016 08:44:51 -0400
Subject: [cmake-developers] [PATCH v3 2/7] Deprecate const char*
 SystemTools::GetEnv function
In-Reply-To: <20160706191213.16242-2-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-2-davispuh@gmail.com>
Message-ID: <577E4EC3.2020706@kitware.com>

On 07/06/2016 03:12 PM, D?vis Mos?ns wrote:
> On Windows this function returns environment variable encoded
> in ANSI codepage which might not match internally used encoding.
[snip]
> -  static const char* GetEnv(const char* key);
> -  static const char* GetEnv(const std::string& key);
> +  DEPRECATED static const char* GetEnv(const char* key);
> +  DEPRECATED static const char* GetEnv(const std::string& key);

Please also revise these to return the properly converted string
and use a static std::map internally to manage the storage.  I'd
like the two overloads to at least return consistent values.  The
need for the internal map is a good justification for adding the
deprecation mark.

Thanks,
-Brad

From brad.king at kitware.com  Thu Jul  7 08:44:58 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 7 Jul 2016 08:44:58 -0400
Subject: [cmake-developers] [PATCH v3 4/7] For Windows encode process
 output to internally used encoding
In-Reply-To: <20160706191213.16242-4-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-4-davispuh@gmail.com>
Message-ID: <577E4ECA.4030001@kitware.com>

On 07/06/2016 03:12 PM, D?vis Mos?ns wrote:
> Typically Windows applications (eg. MSVC compiler) use current console's
> codepage for output to pipes so we need to encode that to internally used
> encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).

We can't do that here.  KWSys Process is a low-level process execution
API and can make no assumptions about the kind of output that comes
from the child.  It might be text or binary, and so cannot be transformed
at this layer in any way.

Higher-level clients within CMake will have to be taught to do the conversion
in cases that the output is expected to be text.  While at it, there was
some discussion a few months ago about newline conversion that needs the
same treatment.

Thanks,
-Brad


From konstantin at podsvirov.pro  Thu Jul  7 09:13:12 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 07 Jul 2016 16:13:12 +0300
Subject: [cmake-developers] [CpackIFW] Fix bug in
	cpack_ifw_configure_... commands
In-Reply-To: <577E4EB3.9070500@kitware.com>
References: <769801467891828@web23o.yandex.ru> <577E4EB3.9070500@kitware.com>
Message-ID: <1379971467897192@web8o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160707/de56f133/attachment.html>

From brad.king at kitware.com  Thu Jul  7 09:39:36 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 7 Jul 2016 09:39:36 -0400
Subject: [cmake-developers] ExternalProject default downloaded file name
In-Reply-To: <f0c15bd1-53a8-bc7c-b403-540be6dfbed9@yahoo.com>
References: <5fefcd08-588a-03e4-98a7-679bb964e762@yahoo.com>
 <577668E8.8070306@kitware.com>
 <40a021fd-9e22-0763-fcb6-5ab06c75892b@yahoo.com>
 <5776C60F.8070901@kitware.com> <577C0493.7060303@kitware.com>
 <cae9cb71-c011-3f60-87ce-625cb08e0465@yahoo.com>
 <577C17E2.1040109@kitware.com>
 <36eb8066-3dfc-238f-bf67-38e20113304e@yahoo.com>
 <577D1787.8050503@kitware.com>
 <f0c15bd1-53a8-bc7c-b403-540be6dfbed9@yahoo.com>
Message-ID: <577E5B98.7080603@kitware.com>

On 07/06/2016 12:07 PM, Ruslan Baratov wrote:
> Attaching rebased patch.

Thanks, applied with some re-wording:

 ExternalProject: Use default file name if extracting from URL fails
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af7da934

-Brad


From tobias.hunger at gmail.com  Thu Jul  7 09:47:49 2016
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Thu, 7 Jul 2016 15:47:49 +0200
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <nlat0i$jfv$1@ger.gmane.org>
References: <1467294716.811.298.camel@qt.io> <nlat0i$jfv$1@ger.gmane.org>
Message-ID: <CAMdWP3GCDtZ0LietojLf50qSpe28eoLNDPKZwGSN9SgEM9BJhA@mail.gmail.com>

Sorry for the late reply... we had a beta release and a new patch
level release out this week and I had to fix some bugs in both:-)

On Sun, Jul 3, 2016 at 1:30 PM, Stephen Kelly <steveire at gmail.com> wrote:
>> "KDevelop3",
>
> <off topic> This generator should probably be removed/hidden by now. It has
> confused users of more-recent KDevelop versions.

Yes, that should be hidden. I'll add that in the next update.

>> What do you think? What else should we report here?
>
> It looks like a good start. The intention of the output is to satisfy needs
> that consumers like you have, and I guess it does have what you need.

Obviously, or I would not propose it:-)

The hope is to get feedback from other potential users. But so far no
luck on that front:-/

>> Compared to the bug report mentioned above the fields "multiconfig" and
>> "recursive" are missing. I could not figure out how to get that
>> information:-/
>
> When I made the example in the issue tracker, 'recursive' meant 'you can cd
> to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was
> possible to do that when using the Makefiles generator, but not the Ninja
> generator.
>
> I think that capability has since been added for the Ninja generator, but I
> don't know if it is possible with the Xcode and VS generators.
>
> Would that be a useful thing to expose here in your view?

I think that information would be useful at some point. But it is not
needed before a project is opened.

>> I would also welcome some code review on the patch.
>
> 1) For consistency you should change
>
>  GetRegisteredGenerators
>
> to
>
>  this->GetRegisteredGenerators
>
> whether that is a preferred style is orthogonal to the fact that it's
> consistently used in cmake code.

Oh, sorry. I still find that horrible to read, so I only sprinkle
this-> over the code shortly before sending it in to review.

> 2) CMake has to build with toolchains which do not provide
> std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing
> code which uses either std::unordered_map or std::unordered_map. (Yes there
> is room for improvement there, but such improvement is orthogonal to your
> branch).

Oh, too bad.

> 3) Similarly, CMake has to build with compilers which do not support
> cxx_range_for or cxx_auto_type. For the cmServer implementation that may or
> may not be the case, but within the cmake class, that's the way it is.

I'll fix that.

> 4) It seems that the
>
>  this->Generators
>
> member of the cmake class has the names of all generators (without 'extra'
> generators). It seems unfortunate to not use that container and instead
> parse the names out of the names from the GetRegisteredGenerators call by
> splitting on the ' - '. It leads to hard coded magic expressions like
> 'separator + 3', so it should be avoided if possible.

Yes, that is ugly.

> Is there another way of determining the extra generators supported by a
> given generator and avoiding parsing a string which we just generated? Can
>
>   const std::vector<std::string>& supportedGlobalGenerators =
>     extraGenerator->GetSupportedGlobalGenerators();
>
> be used somehow? Can you first loop over this->Generators to get the
> 'normal' generators, then loop over the extra generators, call that method
> to match things up and output the result?

Doesn't this require me to instanciate the generators? Won't that  be
potentially expensive?

> Or would it make sense to refactor the container members in the cmake class
> themselves to make this information more easily available for this use-case?
>
> 5) You use the term 'appendix' for the version, but 'suffix' is the more-
> commonly used name for that concept.

I'll change that.

Best Regards,
Tobias

From tobias.hunger at gmail.com  Thu Jul  7 09:51:52 2016
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Thu, 7 Jul 2016 15:51:52 +0200
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <nleskh$qcc$1@ger.gmane.org>
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io> <nlapmk$239$1@ger.gmane.org>
 <1467620290.846.9.camel@qt.io> <nleskh$qcc$1@ger.gmane.org>
Message-ID: <CAMdWP3H0YAEcgmxrVafV43TT=_Z-ZAig3SYEQJaWVovfa1POXA@mail.gmail.com>

Hello,

On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly <steveire at gmail.com>,
me, Stephen Kelly wrote:
>>> Such a feature would also work with cmake projects if the user chooses to
>>> use the XCode generator on mac or VS generator on Windows (or if someday
>>> we have a multi-config Ninja generator or so).
>>
>> How is a multi-config ninja generator better than just having to build
>> directories next to each other, each with one configuration? You might
>> save a bit of disk space (probably not a lot). Will you save a significant
>> amount of processing time?
>>
>> The one benefit I can think of is switching between configurations will
>> probably be a lot faster. But that is nothing that is done so often that
>> it warrants optimizing for IMHO.
>
> What I have in mind is not optimization. As you say, if this is not needed
> at this point for IDE integration, then we can drop the idea.

I still do not get why this feature exists at all. What is the benefit
of having it? Is it just because xcode supports it, so cmake should
to?

>> Either the clients do not care or they need to know which configurations
>> those are going to be.
>
> This can be retrieved by reading the STRINGS property of the
> CMAKE_BUILD_TYPE cache variable.

Oh, that sounds interesting. I'll need to investigate this:-)

Best Regards,
Tobias

From robert.maynard at kitware.com  Thu Jul  7 13:12:02 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 7 Jul 2016 13:12:02 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.0 available for download
Message-ID: <CAFzjYVoBKW0PNcNtW=dOG9vy+vqY5qtOKxDmwe0ToTc3n6B9Tw@mail.gmail.com>

I am proud to announce that CMake 3.6.0 is now available for download at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.6

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.6/release/3.6.html

Some of the more significant features of CMake 3.6 are:

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.

* A "<LANG>_CLANG_TIDY" target property and supporting
  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.

Deprecated and Removed Features
===============================

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "Visual Studio 7 .NET 2003" generator is now deprecated and
  will be removed in a future version of CMake.

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.



CMake 3.6 Release Notes
***********************

Changes made since CMake 3.5 include the following.


New Features
============


Generators
----------

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/all" to drive the build of a subdirectory. This is
  equivalent to "cd sub/dir; make all" with Makefile Generators.

* The "Ninja" generator now includes system header files in build
  dependencies to ensure correct re-builds when system packages are
  updated.

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
  property.

* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
  leave installation rules out of the default installation.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%s" placeholder.  This is the number of seconds
  since the UNIX Epoch.


Variables
---------

* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
  Makefile Generators to limit dependency scanning only to files in
  the project source and build trees.

* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
  when CMake is running on an Oracle Solaris host.

* A "CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES" variable was added
  for use by toolchain files to specify system include directories to
  be appended to all compiler command lines.

* The "CMAKE_<LANG>_STANDARD_LIBRARIES" variable is now documented.
  It is intended for use by toolchain files to specify system
  libraries to be added to all linker command lines.

* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
  the "Ninja" generator to configure the generated "build.ninja" file
  for use as a "subninja".

* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
  use by toolchain files to specify platform-specific variables that
  must be propagated by the "try_compile()" command into test
  projects.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.


Properties
----------

* A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to
  tell the "Visual Studio 9 2008" and "Visual Studio 8 2005"
  generators to generate the "remote directory" for WinCE project
  deployment and debugger settings.

* A "<LANG>_CLANG_TIDY" target property and supporting
  "CMAKE_<LANG>_CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally
  tell CTest to enforce a secondary timeout after matching certain
  output from a test.

* A "VS_CONFIGURATION_TYPE" target property was introduced to
  specify a custom project file type for Visual Studio Generators
  supporting VS 2010 and above.

* A "VS_STARTUP_PROJECT" directory property was introduced to
  specify for Visual Studio Generators the default startup project for
  generated solutions (".sln" files).


Modules
-------

* The "CMakePushCheckState" module now pushes/pops/resets the
  variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize".

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1"
  argument to skip extracting the file that is downloaded (e.g., for
  self-extracting shell installers or ".msi" files).

* The "ExternalProject" module now uses "TLS_VERIFY" when fetching
  from git repositories.

* The "FindBLAS" and "FindLAPACK" modules learned to support
  OpenBLAS.

* The "FindCUDA" module learned to find the "cublas_device" library.

* The "FindGTest" module "gtest_add_tests" function now causes CMake
  to automatically re-run when test sources change so that they can be
  re-scanned.

* The "FindLTTngUST" module was introduced to find the LTTng-UST
  library.

* The "FindPkgConfig" module learned to optionally create imported
  targets for the libraries it has found.

* The "FindProtobuf" module learned to provide a "Protobuf_VERSION"
  variable and check the version number requested in a
  "find_package()" call.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.


Platforms
---------

* The Clang compiler is now supported on CYGWIN.

* Support was added for the Bruce C Compiler with compiler id
  "Bruce".


CTest
-----

* The "ctest_update()" command now looks at the
  "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules
  should be updated or not before updating.

* The "ctest_update()" command will now synchronize submodules on an
  update. Updates which add submodules or change a submodule's URL
  will now be pulled properly.


CPack
-----

* The "CPackDeb" module learned how to handle "$ORIGIN" in
  "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used
  for dependency auto detection.

* The "CPackDeb" module learned how to generate "DEBIAN/shlibs"
  contorl file when package contains shared libraries.

* The "CPackDeb" module learned how to generate "DEBIAN/postinst"
  and "DEBIAN/postrm" files if the package installs libraries in
  ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/").

* The "CPackDeb" module learned how to generate dependencies between
  Debian packages if multi-component setup is used and
  "CPACK_COMPONENT_<compName>_DEPENDS" variables are set. For backward
  compatibility this feature is disabled by default. See
  "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS".

* The "CPackDeb" module learned how to set custom package file names
  including how to generate properly-named Debian packages:

     <PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

  For backward compatibility this feature is disabled by default. See
  "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN_<COMPONENT>_FILE_NAME".

* The "CPackDeb" module learned how to set the package release
  number ("DebianRevisionNumber" in package file name when used in
  combination with "DEB-DEFAULT" value set by
  "CPACK_DEBIAN_FILE_NAME").  See "CPACK_DEBIAN_PACKAGE_RELEASE".

* The "CPackDeb" module learned how to set the package architecture
  per-component.  See "CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE".

* The "CPackDMG" module learned a new option to tell the CPack
  "DragNDrop" generaor to skip the "/Applications" symlink. See the
  "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable.

* The "CPackIFW" module gained a new "cpack_ifw_update_repository()"
  command to update a QtIFW-specific repository from a remote
  repository.

* The "CPackRPM" module learned how to set RPM "dist" tag as part of
  RPM "Release:" tag when enabled (mandatory on some Linux
  distributions for e.g. on Fedora). See
  "CPACK_RPM_PACKAGE_RELEASE_DIST".

* The "CPackRPM" module learned how to set default values for owning
  user/group and file/directory permissions of package content. See
  "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP",
  "CPACK_RPM_DEFAULT_FILE_PERMISSIONS",
  "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component
  counterparts.

* The "CPackRPM" module learned how to set user defined package file
  names, how to specify that rpmbuild should decide on file name
  format as well as handling of multiple rpm packages generated by a
  single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and
  "CPACK_RPM_<component>_PACKAGE_NAME".

* The "CPackRPM" module learned how to correctly handle symlinks
  that are pointing outside generated packages.


Other
-----

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.


Deprecated and Removed Features
===============================

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "find_library()", "find_path()", and "find_file()" commands no
  longer search in installation prefixes derived from the "PATH"
  environment variable on non-Windows platforms.  This behavior was
  added in CMake 3.3 to support Windows hosts but has proven
  problematic on UNIX hosts. Users that keep some "<prefix>/bin"
  directories in the "PATH" just for their tools do not necessarily
  want any supporting "<prefix>/lib" directories searched.  One may
  set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of
  prefixes that are to be searched.

* The "Visual Studio 7 .NET 2003" generator is now deprecated and
  will be removed in a future version of CMake.

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.


Other Changes
=============

* The precompiled OS X binary provided on "cmake.org" now requires
  OS X 10.7 or newer.

* On Linux and FreeBSD platforms, when building CMake itself from
  source and not using a system-provided libcurl, OpenSSL is now used
  by default if it is found on the system.  This enables SSL/TLS
  support for commands supporting network communication via "https",
  such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()".

* The "cmake(1)" "--build" command-line tool now rejects multiple
  "-- target" options with an error instead of silently ignoring all
  but the last one.

* "AUTOMOC" now diagnoses name collisions when multiple source files
  in different directories use "#include <moc_foo.cpp>" with the same
  name (because the generated "moc_foo.cpp" files would collide).

* The "FindBISON" module "BISON_TARGET" macro now supports special
  characters by passing the "VERBATIM" option to internal
  "add_custom_command()" calls.  This may break clients that added
  escaping manually to work around the bug.

* The "FindFLEX" module "FLEX_TARGET" macro now supports special
  characters by passing the "VERBATIM" option to internal
  "add_custom_command()" calls.  This may break clients that added
  escaping manually to work around the bug.

* The "FindProtobuf" module input and output variables were all
  renamed from "PROTOBUF_" to "Protobuf_" for consistency with other
  find modules. Input variables of the old case will be honored if
  provided, and output variables of the old case are always provided.

* The "CPackRPM" module now supports upper cased component names in
  per component CPackRPM specific variables. E.g. component named
  "foo" now expects component specific variable to be
  "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected
  "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in
  variables is compatible with convention used for other CPack
  variables. For back compatibility old format of variables is still
  valid and preferred if both versions of variable are set, but the
  preferred future use is upper cased component names in variables.
  New variables that will be added to CPackRPM in later versions will
  only support upper cased component variable format.

----------------------------------------------------------------------------
Changes made since CMake 3.6.0-rc4:

Brad King (4):
      InstallRequiredSystemLibraries: Document UCRT option use case
      Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example
      clang-format.bash: Fix filter-branch example documentation
      CMake 3.6.0

Konstantin Podsvirov (1):
      CPackIFW: Fix attributes for Promoting Updates repository replacement

O Libre (1):
      FindJNI: Fix support for Ubuntu 15.10

From davispuh at gmail.com  Thu Jul  7 17:54:03 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Fri,  8 Jul 2016 00:54:03 +0300
Subject: [cmake-developers] [PATCH v4 1/4] On Windows use correct encoding
	for SystemTools::GetEnv
Message-ID: <20160707215406.16180-1-davispuh@gmail.com>

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
instead and encode that.

Also add SystemTools::HasEnv function.
---
 Source/kwsys/SystemTools.cxx    | 78 +++++++++++++++++++++++++++++++++++------
 Source/kwsys/SystemTools.hxx.in |  4 +++
 2 files changed, 72 insertions(+), 10 deletions(-)

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..fc1d756 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -406,6 +406,9 @@ struct SystemToolsPathCaseCmp
 class SystemToolsPathCaseMap:
   public std::map<std::string, std::string,
                         SystemToolsPathCaseCmp> {};
+
+class SystemToolsEnvMap :
+    public std::map<std::string,std::string> {};
 #endif
 
 // adds the elements of the env variable path to the arg passed in
@@ -458,7 +461,21 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
 
 const char* SystemTools::GetEnv(const char* key)
 {
-  return getenv(key);
+  const char *v;
+#if defined(_WIN32)
+  const std::string env = SystemTools::GetEnv(key);
+  const std::string skey = key;
+  SystemToolsEnvMap::iterator i = EnvMap->find(skey);
+  if (i != EnvMap->end()) {
+    i->second = env;
+  } else {
+    i = EnvMap->insert(SystemToolsEnvMap::value_type(skey, env)).first;
+  }
+  v = i->second.c_str();
+#else
+  v = getenv(key);
+#endif
+  return v;
 }
 
 const char* SystemTools::GetEnv(const std::string& key)
@@ -468,16 +485,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+    result = Encoding::ToNarrow(wv);
+    return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-    {
+  if (v) {
     result = v;
     return true;
-    }
-  else
-    {
-    return false;
-    }
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -485,6 +507,22 @@ bool SystemTools::GetEnv(const std::string& key, std::string& result)
   return SystemTools::GetEnv(key.c_str(), result);
 }
 
+bool SystemTools::HasEnv(const char* key)
+{
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* v = _wgetenv(wkey.c_str());
+#else
+  const char* v = getenv(key);
+#endif
+  return v != 0;
+}
+
+bool SystemTools::HasEnv(const std::string& key)
+{
+  return SystemTools::HasEnv(key.c_str());
+}
+
 //----------------------------------------------------------------------------
 
 #if defined(__CYGWIN__) || defined(__GLIBC__)
@@ -533,13 +571,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0)
     {
     err = errno;
     }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
     {
     err = errno;
     }
@@ -679,7 +729,12 @@ public:
     static_cast<void>(oldEnv);
     char* newEnv = strdup(env);
     this->insert(newEnv);
+#if defined(_WIN32)
+    const std::wstring wEnv = Encoding::ToWide(newEnv);
+    return _wputenv(wEnv.c_str()) == 0;
+#else
     return putenv(newEnv) == 0;
+#endif
     }
   bool UnPut(const char* env)
     {
@@ -5371,6 +5426,7 @@ static unsigned int SystemToolsManagerCount;
 SystemToolsTranslationMap *SystemTools::TranslationMap;
 #ifdef _WIN32
 SystemToolsPathCaseMap *SystemTools::PathCaseMap;
+SystemToolsEnvMap *SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
 SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
@@ -5421,6 +5477,7 @@ void SystemTools::ClassInitialize()
   SystemTools::TranslationMap = new SystemToolsTranslationMap;
 #ifdef _WIN32
   SystemTools::PathCaseMap = new SystemToolsPathCaseMap;
+  SystemTools::EnvMap = new SystemToolsEnvMap;
 #endif
 #ifdef __CYGWIN__
   SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
@@ -5480,6 +5537,7 @@ void SystemTools::ClassFinalize()
   delete SystemTools::TranslationMap;
 #ifdef _WIN32
   delete SystemTools::PathCaseMap;
+  delete SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
   delete SystemTools::Cyg2Win32Map;
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..8f01e75 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -53,6 +53,7 @@ namespace @KWSYS_NAMESPACE@
 
 class SystemToolsTranslationMap;
 class SystemToolsPathCaseMap;
+class SystemToolsEnvMap;
 
 /** \class SystemToolsManager
  * \brief Use to make sure SystemTools is initialized before it is used
@@ -843,6 +844,8 @@ public:
   static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
+  static bool HasEnv(const char* key);
+  static bool HasEnv(const std::string& key);
 
   /** Put a string into the environment
       of the form var=value */
@@ -989,6 +992,7 @@ private:
   static SystemToolsTranslationMap *TranslationMap;
 #ifdef _WIN32
   static SystemToolsPathCaseMap *PathCaseMap;
+  static SystemToolsEnvMap *EnvMap;
 #endif
 #ifdef __CYGWIN__
   static SystemToolsTranslationMap *Cyg2Win32Map;
-- 
2.9.0


From davispuh at gmail.com  Thu Jul  7 17:54:05 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Fri,  8 Jul 2016 00:54:05 +0300
Subject: [cmake-developers] [PATCH v4 3/4] Use SystemTools::GetEnv and
	HasEnv functions
In-Reply-To: <20160707215406.16180-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
Message-ID: <20160707215406.16180-3-davispuh@gmail.com>

---
 Source/CPack/cmCPackGenerator.cxx           |  8 +++---
 Source/CTest/cmCTestCoverageHandler.cxx     | 12 ++++-----
 Source/CTest/cmCTestCurl.cxx                | 27 ++++++++++----------
 Source/CTest/cmCTestMultiProcessHandler.cxx |  8 +++---
 Source/cmBuildCommand.cxx                   | 25 +++++++++----------
 Source/cmCLocaleEnvironmentScope.cxx        |  5 ++--
 Source/cmCTest.cxx                          | 11 +++++----
 Source/cmCommandArgumentParserHelper.cxx    |  8 +++---
 Source/cmConditionEvaluator.cxx             |  2 +-
 Source/cmExportCommand.cxx                  |  5 ++--
 Source/cmExtraEclipseCDT4Generator.cxx      |  9 ++++---
 Source/cmFileCommand.cxx                    | 11 +++++----
 Source/cmFindPackageCommand.cxx             |  4 +--
 Source/cmGlobalVisualStudio7Generator.cxx   |  6 ++---
 Source/cmMakefile.cxx                       |  5 +++-
 Source/cmNinjaTargetGenerator.cxx           |  2 +-
 Source/cmQtAutoGenerators.cxx               |  2 +-
 Source/cmSetCommand.cxx                     |  7 +++---
 Source/cmState.cxx                          |  5 ++--
 Source/cmSystemTools.cxx                    |  6 ++---
 Source/cmTimestamp.cxx                      |  7 +++---
 Source/cmUtils.hxx                          | 26 ++++++++++++++++++++
 Source/cmake.cxx                            | 21 +++++-----------
 Source/cmcmd.cxx                            | 16 +++++-------
 Source/kwsys/SystemInformation.cxx          | 20 +++++++--------
 Source/kwsys/SystemTools.cxx                | 38 +++++++++++------------------
 Source/kwsys/testSystemTools.cxx            |  9 ++++---
 27 files changed, 156 insertions(+), 149 deletions(-)
 create mode 100644 Source/cmUtils.hxx

diff --git a/Source/CPack/cmCPackGenerator.cxx b/Source/CPack/cmCPackGenerator.cxx
index df8bb0f..76609e1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1074,11 +1074,11 @@ const char* cmCPackGenerator::GetInstallPath()
     return this->InstallPath.c_str();
   }
 #if defined(_WIN32) && !defined(__CYGWIN__)
-  const char* prgfiles = cmsys::SystemTools::GetEnv("ProgramFiles");
-  const char* sysDrive = cmsys::SystemTools::GetEnv("SystemDrive");
-  if (prgfiles) {
+  std::string prgfiles;
+  std::string sysDrive;
+  if (cmsys::SystemTools::GetEnv("ProgramFiles", prgfiles)) {
     this->InstallPath = prgfiles;
-  } else if (sysDrive) {
+  } else if (cmsys::SystemTools::GetEnv("SystemDrive", sysDrive)) {
     this->InstallPath = sysDrive;
     this->InstallPath += "/Program Files";
   } else {
diff --git a/Source/CTest/cmCTestCoverageHandler.cxx b/Source/CTest/cmCTestCoverageHandler.cxx
index 7102533..9410a52 100644
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@ -727,10 +727,7 @@ int cmCTestCoverageHandler::HandleCoberturaCoverage(
   // if it doesn't exist or is empty, assume the
   // binary directory is used.
   std::string coverageXMLFile;
-  const char* covDir = cmSystemTools::GetEnv("COBERTURADIR");
-  if (covDir && strlen(covDir) != 0) {
-    coverageXMLFile = std::string(covDir);
-  } else {
+  if (!cmSystemTools::GetEnv("COBERTURADIR", coverageXMLFile) || coverageXMLFile.empty()) {
     coverageXMLFile = this->CTest->GetBinaryDir();
   }
   // build the find file string with the directory from above
@@ -791,7 +788,8 @@ struct cmCTestCoverageHandlerLocale
 {
   cmCTestCoverageHandlerLocale()
   {
-    if (const char* l = cmSystemTools::GetEnv("LC_ALL")) {
+    std::string l;
+    if (cmSystemTools::GetEnv("LC_ALL", l)) {
       lc_all = l;
     }
     if (lc_all != "C") {
@@ -2121,8 +2119,8 @@ int cmCTestCoverageHandler::RunBullseyeSourceSummary(
 int cmCTestCoverageHandler::HandleBullseyeCoverage(
   cmCTestCoverageHandlerContainer* cont)
 {
-  const char* covfile = cmSystemTools::GetEnv("COVFILE");
-  if (!covfile || strlen(covfile) == 0) {
+  std::string covfile;
+  if (!cmSystemTools::GetEnv("COVFILE", covfile) || covfile.empty()) {
     cmCTestOptionalLog(this->CTest, HANDLER_VERBOSE_OUTPUT,
                        " COVFILE environment variable not found, not running "
                        " bullseye\n",
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index 6b8e5b5..b335e32 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -219,16 +219,18 @@ bool cmCTestCurl::HttpRequest(std::string const& url,
 
 void cmCTestCurl::SetProxyType()
 {
-  if (cmSystemTools::GetEnv("HTTP_PROXY")) {
-    this->HTTPProxy = cmSystemTools::GetEnv("HTTP_PROXY");
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT")) {
+  this->HTTPProxy = "";
+  // this is the default
+  this->HTTPProxyType = CURLPROXY_HTTP;
+  this->HTTPProxyAuth = "";
+  if (cmSystemTools::GetEnv("HTTP_PROXY", this->HTTPProxy)) {
+    std::string port;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PORT", port)) {
       this->HTTPProxy += ":";
-      this->HTTPProxy += cmSystemTools::GetEnv("HTTP_PROXY_PORT");
+      this->HTTPProxy += port;
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE")) {
-      // this is the default
-      this->HTTPProxyType = CURLPROXY_HTTP;
-      std::string type = cmSystemTools::GetEnv("HTTP_PROXY_TYPE");
+    std::string type;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_TYPE", type)) {
       // HTTP/SOCKS4/SOCKS5
       if (type == "HTTP") {
         this->HTTPProxyType = CURLPROXY_HTTP;
@@ -238,12 +240,11 @@ void cmCTestCurl::SetProxyType()
         this->HTTPProxyType = CURLPROXY_SOCKS5;
       }
     }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_USER")) {
-      this->HTTPProxyAuth = cmSystemTools::GetEnv("HTTP_PROXY_USER");
-    }
-    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD")) {
+    cmSystemTools::GetEnv("HTTP_PROXY_USER", this->HTTPProxyAuth);
+    std::string passwd;
+    if (cmSystemTools::GetEnv("HTTP_PROXY_PASSWD", passwd)) {
       this->HTTPProxyAuth += ":";
-      this->HTTPProxyAuth += cmSystemTools::GetEnv("HTTP_PROXY_PASSWD");
+      this->HTTPProxyAuth += passwd;
     }
   }
 }
diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx b/Source/CTest/cmCTestMultiProcessHandler.cxx
index ae97d32..ffd51c7 100644
--- a/Source/CTest/cmCTestMultiProcessHandler.cxx
+++ b/Source/CTest/cmCTestMultiProcessHandler.cxx
@@ -261,12 +261,12 @@ void cmCTestMultiProcessHandler::StartNextTests()
     allTestsFailedTestLoadCheck = true;
 
     // Check for a fake load average value used in testing.
-    if (const char* fake_load_value =
-          cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING")) {
+    std::string fake_load_value;
+    if (cmSystemTools::GetEnv("__CTEST_FAKE_LOAD_AVERAGE_FOR_TESTING", fake_load_value)) {
       usedFakeLoadForTesting = true;
-      if (!cmSystemTools::StringToULong(fake_load_value, &systemLoad)) {
+      if (!cmSystemTools::StringToULong(fake_load_value.c_str(), &systemLoad)) {
         cmSystemTools::Error("Failed to parse fake load value: ",
-                             fake_load_value);
+                             fake_load_value.c_str());
       }
     }
     // If it's not set, look up the true load average.
diff --git a/Source/cmBuildCommand.cxx b/Source/cmBuildCommand.cxx
index fb143a2..3dfd9cf 100644
--- a/Source/cmBuildCommand.cxx
+++ b/Source/cmBuildCommand.cxx
@@ -36,8 +36,8 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   const char* variable = args[0].c_str();
 
   // Parse remaining arguments.
-  const char* configuration = CM_NULLPTR;
-  const char* project_name = CM_NULLPTR;
+  std::string configuration;
+  std::string project_name;
   std::string target;
   enum Doing
   {
@@ -56,10 +56,10 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
       doing = DoingTarget;
     } else if (doing == DoingConfiguration) {
       doing = DoingNone;
-      configuration = args[i].c_str();
+      configuration = args[i];
     } else if (doing == DoingProjectName) {
       doing = DoingNone;
-      project_name = args[i].c_str();
+      project_name = args[i];
     } else if (doing == DoingTarget) {
       doing = DoingNone;
       target = args[i];
@@ -76,14 +76,14 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
   // so we put this code here to end up with the same default configuration
   // as the original 2-arg build_command signature:
   //
-  if (!configuration || !*configuration) {
-    configuration = getenv("CMAKE_CONFIG_TYPE");
+  if (configuration.empty()) {
+    cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configuration);
   }
-  if (!configuration || !*configuration) {
+  if (configuration.empty()) {
     configuration = "Release";
   }
 
-  if (project_name && *project_name) {
+  if (!project_name.empty()) {
     this->Makefile->IssueMessage(
       cmake::AUTHOR_WARNING,
       "Ignoring PROJECT_NAME option because it has no effect.");
@@ -91,7 +91,7 @@ bool cmBuildCommand::MainSignature(std::vector<std::string> const& args)
 
   std::string makecommand =
     this->Makefile->GetGlobalGenerator()->GenerateCMakeBuildCommand(
-      target, configuration, "", this->Makefile->IgnoreErrorsCMP0061());
+      target, configuration.c_str(), "", this->Makefile->IgnoreErrorsCMP0061());
 
   this->Makefile->AddDefinition(variable, makecommand.c_str());
 
@@ -108,10 +108,9 @@ bool cmBuildCommand::TwoArgsSignature(std::vector<std::string> const& args)
   const char* define = args[0].c_str();
   const char* cacheValue = this->Makefile->GetDefinition(define);
 
-  std::string configType = "Release";
-  const char* cfg = getenv("CMAKE_CONFIG_TYPE");
-  if (cfg && *cfg) {
-    configType = cfg;
+  std::string configType;
+  if (!cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE", configType) || configType.empty()) {
+    configType = "Release";
   }
 
   std::string makecommand =
diff --git a/Source/cmCLocaleEnvironmentScope.cxx b/Source/cmCLocaleEnvironmentScope.cxx
index a19dbae..e4c74ec 100644
--- a/Source/cmCLocaleEnvironmentScope.cxx
+++ b/Source/cmCLocaleEnvironmentScope.cxx
@@ -31,8 +31,9 @@ cmCLocaleEnvironmentScope::cmCLocaleEnvironmentScope()
 
 std::string cmCLocaleEnvironmentScope::GetEnv(std::string const& key)
 {
-  const char* value = cmSystemTools::GetEnv(key);
-  return value ? value : std::string();
+  std::string value;
+  cmSystemTools::GetEnv(key, value);
+  return value;
 }
 
 void cmCLocaleEnvironmentScope::SetEnv(std::string const& key,
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 3bb997a..05dd245 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -298,9 +298,9 @@ cmCTest::cmCTest()
   this->ComputedCompressMemCheckOutput = false;
   this->RepeatTests = 1; // default to run each test once
   this->RepeatUntilFail = false;
-  if (const char* outOnFail =
-        cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE")) {
-    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail);
+  std::string outOnFail;
+  if (cmSystemTools::GetEnv("CTEST_OUTPUT_ON_FAILURE", outOnFail)) {
+    this->OutputTestOutputOnTestFailure = !cmSystemTools::IsOff(outOnFail.c_str());
   }
   this->InitStreams();
 
@@ -2091,8 +2091,9 @@ int cmCTest::Run(std::vector<std::string>& args, std::string* output)
 
   // handle CTEST_PARALLEL_LEVEL environment variable
   if (!this->ParallelLevelSetInCli) {
-    if (const char* parallel = cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL")) {
-      int plevel = atoi(parallel);
+    std::string parallel;
+    if (cmSystemTools::GetEnv("CTEST_PARALLEL_LEVEL", parallel)) {
+      int plevel = atoi(parallel.c_str());
       this->SetParallelLevel(plevel);
     }
   }
diff --git a/Source/cmCommandArgumentParserHelper.cxx b/Source/cmCommandArgumentParserHelper.cxx
index 294117c..42fb105 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -71,12 +71,12 @@ char* cmCommandArgumentParserHelper::ExpandSpecialVariable(const char* key,
     return this->EmptyVariable;
   }
   if (strcmp(key, "ENV") == 0) {
-    char* ptr = getenv(var);
-    if (ptr) {
+    std::string str;
+    if (cmSystemTools::GetEnv(var, str)) {
       if (this->EscapeQuotes) {
-        return this->AddString(cmSystemTools::EscapeQuotes(ptr));
+        return this->AddString(cmSystemTools::EscapeQuotes(str.c_str()));
       } else {
-        return ptr;
+        return this->AddString(str);
       }
     }
     return this->EmptyVariable;
diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 67b2571..e02221c 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -486,7 +486,7 @@ bool cmConditionEvaluator::HandleLevel1(cmArgumentList& newArgs, std::string&,
         if (argP1len > 4 && argP1->GetValue().substr(0, 4) == "ENV{" &&
             argP1->GetValue().operator[](argP1len - 1) == '}') {
           std::string env = argP1->GetValue().substr(4, argP1len - 5);
-          bdef = cmSystemTools::GetEnv(env.c_str()) ? true : false;
+          bdef = cmSystemTools::HasEnv(env.c_str());
         } else {
           bdef = this->Makefile.IsDefinitionSet(argP1->GetValue());
         }
diff --git a/Source/cmExportCommand.cxx b/Source/cmExportCommand.cxx
index 3cb575e..fc62492 100644
--- a/Source/cmExportCommand.cxx
+++ b/Source/cmExportCommand.cxx
@@ -327,11 +327,10 @@ void cmExportCommand::StorePackageRegistryDir(std::string const& package,
   fname += "/cmake/packages/";
   fname += package;
 #else
-  const char* home = cmSystemTools::GetEnv("HOME");
-  if (!home) {
+  std::string fname;
+  if (!cmSystemTools::GetEnv("HOME", fname)) {
     return;
   }
-  std::string fname = home;
   cmSystemTools::ConvertToUnixSlashes(fname);
   fname += "/.cmake/packages/";
   fname += package;
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx
index 16cb082..93c55cc 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -208,7 +208,8 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
   // get the variables from the environment and from the cache and then
   // figure out which one to use:
 
-  const char* envVarValue = getenv(envVar);
+  std::string envVarValue;
+  const bool envVarSet = cmSystemTools::GetEnv(envVar, envVarValue);
 
   std::string cacheEntryName = "CMAKE_ECLIPSE_ENVVAR_";
   cacheEntryName += envVar;
@@ -217,17 +218,17 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out,
 
   // now we have both, decide which one to use
   std::string valueToUse;
-  if (envVarValue == CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  if (!envVarSet && cacheValue == CM_NULLPTR) {
     // nothing known, do nothing
     valueToUse = "";
-  } else if (envVarValue != CM_NULLPTR && cacheValue == CM_NULLPTR) {
+  } else if (envVarSet && cacheValue == CM_NULLPTR) {
     // The variable is in the env, but not in the cache. Use it and put it
     // in the cache
     valueToUse = envVarValue;
     mf->AddCacheDefinition(cacheEntryName, valueToUse.c_str(),
                            cacheEntryName.c_str(), cmState::STRING, true);
     mf->GetCMakeInstance()->SaveCache(lg->GetBinaryDirectory());
-  } else if (envVarValue == CM_NULLPTR && cacheValue != CM_NULLPTR) {
+  } else if (!envVarSet && cacheValue != CM_NULLPTR) {
     // It is already in the cache, but not in the env, so use it from the cache
     valueToUse = cacheValue;
   } else {
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 5a1238b..835b118 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -1609,8 +1609,10 @@ struct cmFileInstaller : public cmFileCopier
     // Installation does not use source permissions by default.
     this->UseSourcePermissions = false;
     // Check whether to copy files always or only if they have changed.
-    this->Always =
-      cmSystemTools::IsOn(cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS"));
+    std::string install_always;
+    if (cmSystemTools::GetEnv("CMAKE_INSTALL_ALWAYS", install_always)) {
+      this->Always = cmSystemTools::IsOn(install_always.c_str());
+    }
     // Get the current manifest.
     this->Manifest =
       this->Makefile->GetSafeDefinition("CMAKE_INSTALL_MANIFEST_FILES");
@@ -1869,9 +1871,8 @@ bool cmFileInstaller::HandleInstallDestination()
     return false;
   }
 
-  const char* destdir = cmSystemTools::GetEnv("DESTDIR");
-  if (destdir && *destdir) {
-    std::string sdestdir = destdir;
+  std::string sdestdir;
+  if (cmSystemTools::GetEnv("DESTDIR", sdestdir) && !sdestdir.empty()) {
     cmSystemTools::ConvertToUnixSlashes(sdestdir);
     char ch1 = destination[0];
     char ch2 = destination[1];
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index d5fd75d..260079b 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1077,8 +1077,8 @@ void cmFindPackageCommand::FillPrefixesUserRegistry()
                                  this->LabeledPaths[PathLabel::UserRegistry]);
   }
 #else
-  if (const char* home = cmSystemTools::GetEnv("HOME")) {
-    std::string dir = home;
+  std::string dir;
+  if (cmSystemTools::GetEnv("HOME", dir)) {
     dir += "/.cmake/packages/";
     dir += this->Name;
     this->LoadPackageRegistryDir(dir,
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx b/Source/cmGlobalVisualStudio7Generator.cxx
index 262909f..0a83b3a 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -122,9 +122,9 @@ void cmGlobalVisualStudio7Generator::EnableLanguage(
   // does not use the environment it is run in, and this allows
   // for running commands and using dll's that the IDE environment
   // does not know about.
-  const char* extraPath = cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH");
-  if (extraPath) {
-    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath,
+  std::string extraPath;
+  if (cmSystemTools::GetEnv("CMAKE_MSVCIDE_RUN_PATH", extraPath)) {
+    mf->AddCacheDefinition("CMAKE_MSVCIDE_RUN_PATH", extraPath.c_str(),
                            "Saved environment variable CMAKE_MSVCIDE_RUN_PATH",
                            cmState::STATIC);
   }
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 0d550dd..ab7de57 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2572,6 +2572,7 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
           std::string const& lookup = result.substr(var.loc);
           const char* value = CM_NULLPTR;
           std::string varresult;
+          std::string svalue;
           static const std::string lineVar = "CMAKE_CURRENT_LIST_LINE";
           switch (var.domain) {
             case NORMAL:
@@ -2584,7 +2585,9 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
               }
               break;
             case ENVIRONMENT:
-              value = cmSystemTools::GetEnv(lookup.c_str());
+              if (cmSystemTools::GetEnv(lookup, svalue)) {
+                value = svalue.c_str();
+              }
               break;
             case CACHE:
               value = state->GetCacheEntryValue(lookup);
diff --git a/Source/cmNinjaTargetGenerator.cxx b/Source/cmNinjaTargetGenerator.cxx
index 1d3e608..855a243 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -741,5 +741,5 @@ bool cmNinjaTargetGenerator::ForceResponseFile()
 {
   static std::string const forceRspFile = "CMAKE_NINJA_FORCE_RESPONSE_FILE";
   return (this->GetMakefile()->IsDefinitionSet(forceRspFile) ||
-          cmSystemTools::GetEnv(forceRspFile) != CM_NULLPTR);
+          cmSystemTools::HasEnv(forceRspFile));
 }
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 4b40c08..b821fda 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -88,7 +88,7 @@ static std::string extractSubDir(const std::string& absPath,
 }
 
 cmQtAutoGenerators::cmQtAutoGenerators()
-  : Verbose(cmsys::SystemTools::GetEnv("VERBOSE") != CM_NULLPTR)
+  : Verbose(cmsys::SystemTools::HasEnv("VERBOSE"))
   , ColorOutput(true)
   , RunMocFailed(false)
   , RunUicFailed(false)
diff --git a/Source/cmSetCommand.cxx b/Source/cmSetCommand.cxx
index 1484368..8fb6aa0 100644
--- a/Source/cmSetCommand.cxx
+++ b/Source/cmSetCommand.cxx
@@ -31,13 +31,14 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
     putEnvArg += "=";
 
     // what is the current value if any
-    const char* currValue = getenv(varName);
+    std::string currValue;
+    const bool currValueSet = cmSystemTools::GetEnv(varName, currValue);
     delete[] varName;
 
     // will it be set to something, then set it
     if (args.size() > 1 && !args[1].empty()) {
       // but only if it is different from current value
-      if (!currValue || strcmp(currValue, args[1].c_str())) {
+      if (!currValueSet || currValue != args[1]) {
         putEnvArg += args[1];
         cmSystemTools::PutEnv(putEnvArg);
       }
@@ -45,7 +46,7 @@ bool cmSetCommand::InitialPass(std::vector<std::string> const& args,
     }
 
     // if it will be cleared, then clear it if it isn't already clear
-    if (currValue) {
+    if (currValueSet) {
       cmSystemTools::PutEnv(putEnvArg);
     }
     return true;
diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index f2fe134..0470508 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -1286,8 +1286,9 @@ void cmState::Snapshot::SetDefaultDefinitions()
   this->SetDefinition("CMAKE_HOST_UNIX", "1");
 #endif
 #if defined(__CYGWIN__)
-  if (cmSystemTools::IsOn(
-        cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32"))) {
+  std::string legacy;
+  if (cmSystemTools::GetEnv("CMAKE_LEGACY_CYGWIN_WIN32", legacy) &&
+      cmSystemTools::IsOn(legacy.c_str())) {
     this->SetDefinition("WIN32", "1");
     this->SetDefinition("CMAKE_HOST_WIN32", "1");
   }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 2d463f3..9740ef7 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2069,9 +2069,9 @@ void cmSystemTools::MakefileColorEcho(int color, const char* message,
   // However, we can test for some situations when the answer is most
   // likely no.
   int assumeTTY = cmsysTerminal_Color_AssumeTTY;
-  if (cmSystemTools::GetEnv("DART_TEST_FROM_DART") ||
-      cmSystemTools::GetEnv("DASHBOARD_TEST_FROM_CTEST") ||
-      cmSystemTools::GetEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
+  if (cmSystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      cmSystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST") ||
+      cmSystemTools::HasEnv("CTEST_INTERACTIVE_DEBUG_MODE")) {
     // Avoid printing color escapes during dashboard builds.
     assumeTTY = 0;
   }
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index c3c1d17..61b74db 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -93,10 +93,9 @@ time_t cmTimestamp::CreateUtcTimeTFromTm(struct tm& tm) const
 #else
   // From Linux timegm() manpage.
 
-  std::string tz_old = "TZ=";
-  if (const char* tz = cmSystemTools::GetEnv("TZ")) {
-    tz_old += tz;
-  }
+  std::string tz_old = "";
+  cmSystemTools::GetEnv("TZ", tz_old);
+  tz_old = "TZ=" + tz_old;
 
   // The standard says that "TZ=" or "TZ=[UNRECOGNIZED_TZ]" means UTC.
   // It seems that "TZ=" does NOT work, at least under Windows
diff --git a/Source/cmUtils.hxx b/Source/cmUtils.hxx
new file mode 100644
index 0000000..fd1031e
--- /dev/null
+++ b/Source/cmUtils.hxx
@@ -0,0 +1,26 @@
+/*============================================================================
+  CMake - Cross Platform Makefile Generator
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef cmUtils_hxx
+#define cmUtils_hxx
+
+#include <cmsys/SystemTools.hxx>
+
+// Use the make system's VERBOSE environment variable to enable
+// verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
+// (which is set by the Eclipse and KDevelop generators).
+inline bool isCMakeVerbose() {
+  return (cmSystemTools::HasEnv("VERBOSE") &&
+          !cmSystemTools::HasEnv("CMAKE_NO_VERBOSE"));
+}
+
+#endif
+
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index c597605..e4a9954 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -22,6 +22,7 @@
 #include "cmSourceFile.h"
 #include "cmState.h"
 #include "cmTest.h"
+#include "cmUtils.hxx"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmGraphVizWriter.h"
@@ -955,16 +956,10 @@ void cmake::SetGlobalGenerator(cmGlobalGenerator* gg)
   cmSystemTools::SetForceUnixPaths(this->GlobalGenerator->GetForceUnixPaths());
 
   // Save the environment variables CXX and CC
-  const char* cxx = getenv("CXX");
-  const char* cc = getenv("CC");
-  if (cxx) {
-    this->CXXEnvironment = cxx;
-  } else {
+  if (!cmSystemTools::GetEnv("CXX", this->CXXEnvironment)) {
     this->CXXEnvironment = "";
   }
-  if (cc) {
-    this->CCEnvironment = cc;
-  } else {
+  if (!cmSystemTools::GetEnv("CC", this->CCEnvironment)) {
     this->CCEnvironment = "";
   }
 }
@@ -1429,7 +1424,7 @@ int cmake::Run(const std::vector<std::string>& args, bool noconfigure)
   // should fail (if "-i" is an option).  We cannot simply test
   // whether "-i" is given and remove it because some make programs
   // encode the MAKEFLAGS variable in a strange way.
-  if (getenv("MAKEFLAGS")) {
+  if (cmSystemTools::HasEnv("MAKEFLAGS")) {
     cmSystemTools::PutEnv("MAKEFLAGS=");
   }
 
@@ -1704,12 +1699,8 @@ void cmake::UpdateConversionPathTable()
 
 int cmake::CheckBuildSystem()
 {
-  // We do not need to rerun CMake.  Check dependency integrity.  Use
-  // the make system's VERBOSE environment variable to enable verbose
-  // output. This can be skipped by setting CMAKE_NO_VERBOSE (which is set
-  // by the Eclipse and KDevelop generators).
-  bool verbose = ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-                  (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+  // We do not need to rerun CMake.  Check dependency integrity.
+  const bool verbose = isCMakeVerbose();
 
   // This method will check the integrity of the build system if the
   // option was given on the command line.  It reads the given file to
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 010a3b2..8025d9b 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -17,6 +17,7 @@
 #include "cmMakefile.h"
 #include "cmQtAutoGenerators.h"
 #include "cmVersion.h"
+#include "cmUtils.hxx"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmDependsFortran.h" // For -E cmake_copy_f90_mod callback.
@@ -697,12 +698,7 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
 
     // Internal CMake dependency scanning support.
     else if (args[1] == "cmake_depends" && args.size() >= 6) {
-      // Use the make system's VERBOSE environment variable to enable
-      // verbose output. This can be skipped by also setting CMAKE_NO_VERBOSE
-      // (which is set by the Eclipse and KDevelop generators).
-      bool verbose =
-        ((cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR) &&
-         (cmSystemTools::GetEnv("CMAKE_NO_VERBOSE") == CM_NULLPTR));
+      const bool verbose = isCMakeVerbose();
 
       // Create a cmake object instance to process dependencies.
       cmake cm;
@@ -900,9 +896,9 @@ int cmcmd::ExecuteCMakeCommand(std::vector<std::string>& args)
         // 1/10th of a second after the untar.  If CMAKE_UNTAR_DELAY
         // is set in the env, its value will be used instead of 100.
         int delay = 100;
-        const char* delayVar = cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY");
-        if (delayVar) {
-          delay = atoi(delayVar);
+        std::string delayVar;
+        if (cmSystemTools::GetEnv("CMAKE_UNTAR_DELAY", delayVar)) {
+          delay = atoi(delayVar.c_str());
         }
         if (delay) {
           cmSystemTools::Delay(delay);
@@ -1254,7 +1250,7 @@ int cmcmd::VisualStudioLink(std::vector<std::string>& args, int type)
   if (args.size() < 2) {
     return -1;
   }
-  bool verbose = cmSystemTools::GetEnv("VERBOSE") != CM_NULLPTR;
+  const bool verbose = cmSystemTools::HasEnv("VERBOSE");
   std::vector<std::string> expandedArgs;
   for (std::vector<std::string>::iterator i = args.begin(); i != args.end();
        ++i) {
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 81fb2f9..c84d71f 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -37,12 +37,14 @@
 #include "kwsysPrivate.h"
 #include KWSYS_HEADER(SystemInformation.hxx)
 #include KWSYS_HEADER(Process.h)
+#include KWSYS_HEADER(SystemTools.hxx)
 
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
 #if 0
 # include "SystemInformation.hxx.in"
 # include "Process.h.in"
+# include "SystemTools.hxx.in"
 #endif
 
 #include <iostream>
@@ -3476,10 +3478,10 @@ SystemInformationImplementation::GetHostMemoryAvailable(const char *hostLimitEnv
   // apply a limit across a set of processes. Units are in KiB.
   if (hostLimitEnvVarName)
     {
-    const char *hostLimitEnvVarValue=getenv(hostLimitEnvVarName);
-    if (hostLimitEnvVarValue)
+    std::string hostLimitEnvVarValue;
+    if (SystemTools::GetEnv(hostLimitEnvVarName, hostLimitEnvVarValue))
       {
-      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue);
+      SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue.c_str());
       if (hostLimit>0)
         {
         memTotal=min(hostLimit,memTotal);
@@ -3506,10 +3508,10 @@ SystemInformationImplementation::GetProcMemoryAvailable(
   // are not employed. Units are in KiB.
   if (procLimitEnvVarName)
     {
-    const char *procLimitEnvVarValue=getenv(procLimitEnvVarName);
-    if (procLimitEnvVarValue)
+    std::string procLimitEnvVarValue;
+    if (SystemTools::GetEnv(procLimitEnvVarName, procLimitEnvVarValue))
       {
-      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue);
+      SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue.c_str());
       if (procLimit>0)
         {
         memAvail=min(procLimit,memAvail);
@@ -5408,11 +5410,7 @@ bool SystemInformationImplementation::QueryOSInformation()
     }
   this->Hostname = name;
 
-  const char* arch = getenv("PROCESSOR_ARCHITECTURE");
-  if(arch)
-    {
-    this->OSPlatform = arch;
-    }
+  SystemTools::GetEnv("PROCESSOR_ARCHITECTURE", this->OSPlatform);
 
 #else
 
diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index fc1d756..352a888 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -424,14 +424,12 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
     {
     env = "PATH";
     }
-  const char* cpathEnv = SystemTools::GetEnv(env);
-  if ( !cpathEnv )
+  std::string pathEnv;
+  if ( !SystemTools::GetEnv(env, pathEnv) )
     {
     return;
     }
 
-  std::string pathEnv = cpathEnv;
-
   // A hack to make the below algorithm work.
   if(!pathEnv.empty() && *pathEnv.rbegin() != pathSep)
     {
@@ -2099,8 +2097,8 @@ void SystemTools::ConvertToUnixSlashes(std::string& path)
     pathCString = path.c_str();
     if(pathCString[0] == '~' && (pathCString[1] == '/' || pathCString[1] == '\0'))
       {
-      const char* homeEnv = SystemTools::GetEnv("HOME");
-      if (homeEnv)
+      std::string homeEnv;
+      if (SystemTools::GetEnv("HOME", homeEnv))
         {
         path.replace(0,1,homeEnv);
         }
@@ -4116,16 +4114,9 @@ void SystemTools::SplitPath(const std::string& p,
     if(root.size() == 1)
       {
 #if defined(_WIN32) && !defined(__CYGWIN__)
-      if(const char* userp = getenv("USERPROFILE"))
-        {
-        homedir = userp;
-        }
-      else
+      if (!SystemTools::GetEnv("USERPROFILE", homedir))
 #endif
-      if(const char* h = getenv("HOME"))
-        {
-        homedir = h;
-        }
+      SystemTools::GetEnv("HOME", homedir);
       }
 #ifdef HAVE_GETPWNAM
     else if(passwd* pw = getpwnam(root.c_str()+1))
@@ -4866,7 +4857,7 @@ int SystemTools::GetTerminalWidth()
   int width = -1;
 #ifdef HAVE_TTY_INFO
   struct winsize ws;
-  char *columns; /* Unix98 environment variable */
+  std::string columns; /* Unix98 environment variable */
   if(ioctl(1, TIOCGWINSZ, &ws) != -1 && ws.ws_col>0 && ws.ws_row>0)
     {
     width = ws.ws_col;
@@ -4875,12 +4866,11 @@ int SystemTools::GetTerminalWidth()
     {
     width = -1;
     }
-  columns = getenv("COLUMNS");
-  if(columns && *columns)
+  if(SystemTools::GetEnv("COLUMNS", columns) && !columns.empty())
     {
     long t;
     char *endptr;
-    t = strtol(columns, &endptr, 0);
+    t = strtol(columns.c_str(), &endptr, 0);
     if(endptr && !*endptr && (t>0) && (t<1000))
       {
       width = static_cast<int>(t);
@@ -5492,7 +5482,8 @@ void SystemTools::ClassInitialize()
 
   // If the current working directory is a logical path then keep the
   // logical name.
-  if(const char* pwd = getenv("PWD"))
+  std::string pwd_str;
+  if(SystemTools::GetEnv("PWD", pwd_str))
     {
     char buf[2048];
     if(const char* cwd = Getcwd(buf, 2048))
@@ -5504,10 +5495,9 @@ void SystemTools::ClassInitialize()
       std::string pwd_changed;
 
       // Test progressively shorter logical-to-physical mappings.
-      std::string pwd_str = pwd;
       std::string cwd_str = cwd;
       std::string pwd_path;
-      Realpath(pwd, pwd_path);
+      Realpath(pwd_str.c_str(), pwd_path);
       while(cwd_str == pwd_path && cwd_str != pwd_str)
         {
         // The current pair of paths is a working logical mapping.
@@ -5563,8 +5553,8 @@ static int SystemToolsDebugReport(int, char* message, int*)
 
 void SystemTools::EnableMSVCDebugHook()
 {
-  if (getenv("DART_TEST_FROM_DART") ||
-      getenv("DASHBOARD_TEST_FROM_CTEST"))
+  if (SystemTools::HasEnv("DART_TEST_FROM_DART") ||
+      SystemTools::HasEnv("DASHBOARD_TEST_FROM_CTEST"))
     {
     _CrtSetReportHook(SystemToolsDebugReport);
     }
diff --git a/Source/kwsys/testSystemTools.cxx b/Source/kwsys/testSystemTools.cxx
index 4d97688..4dab347 100644
--- a/Source/kwsys/testSystemTools.cxx
+++ b/Source/kwsys/testSystemTools.cxx
@@ -848,9 +848,9 @@ static bool CheckPutEnv(const std::string& env, const char* name, const char* va
                     << "\") failed!" << std::endl;
     return false;
     }
-  const char* v = kwsys::SystemTools::GetEnv(name);
-  v = v? v : "(null)";
-  if(strcmp(v, value) != 0)
+  std::string v = "(null)";
+  kwsys::SystemTools::GetEnv(name, v);
+  if(v != value)
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not \"" << value << "\"!" << std::endl;
@@ -867,7 +867,8 @@ static bool CheckUnPutEnv(const char* env, const char* name)
                     << std::endl;
     return false;
     }
-  if(const char* v = kwsys::SystemTools::GetEnv(name))
+  std::string v;
+  if(kwsys::SystemTools::GetEnv(name, v))
     {
     std::cerr << "GetEnv(\"" << name << "\") returned \""
                     << v << "\", not (null)!" << std::endl;
-- 
2.9.0


From davispuh at gmail.com  Thu Jul  7 17:54:06 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Fri,  8 Jul 2016 00:54:06 +0300
Subject: [cmake-developers] [PATCH v4 4/4] For Windows encode process output
	to internally used encoding
In-Reply-To: <20160707215406.16180-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
Message-ID: <20160707215406.16180-4-davispuh@gmail.com>

Typically Windows applications (eg. MSVC compiler) use current console's
codepage for output to pipes so we need to encode that to internally used
encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
---
 Source/cmExecProgramCommand.cxx    |  1 +
 Source/cmExecuteProcessCommand.cxx |  1 +
 Source/cmProcessTools.cxx          |  2 ++
 Source/cmSystemTools.cxx           |  3 +++
 Source/kwsys/CMakeLists.txt        |  2 ++
 Source/kwsys/Process.h.in          | 13 +++++++++++++
 Source/kwsys/ProcessUNIX.c         |  6 ++++++
 Source/kwsys/ProcessWin32.c        | 33 ++++++++++++++++++++++++++++++++-
 Source/kwsys/SystemInformation.cxx |  1 +
 9 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/Source/cmExecProgramCommand.cxx b/Source/cmExecProgramCommand.cxx
index 58bbc31..92b89fc 100644
--- a/Source/cmExecProgramCommand.cxx
+++ b/Source/cmExecProgramCommand.cxx
@@ -220,6 +220,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, std::string& output,
   char* data;
   int p;
   while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
+    cmsysProcess_DecodeTextOutput(cp, &data, &length);
     if (p == cmsysProcess_Pipe_STDOUT || p == cmsysProcess_Pipe_STDERR) {
       if (verbose) {
         cmSystemTools::Stdout(data, length);
diff --git a/Source/cmExecuteProcessCommand.cxx b/Source/cmExecuteProcessCommand.cxx
index d97b25f..b13fb2e 100644
--- a/Source/cmExecuteProcessCommand.cxx
+++ b/Source/cmExecuteProcessCommand.cxx
@@ -229,6 +229,7 @@ bool cmExecuteProcessCommand::InitialPass(std::vector<std::string> const& args,
   char* data;
   int p;
   while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
+    cmsysProcess_DecodeTextOutput(cp, &data, &length);
     // Put the output in the right place.
     if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
       if (output_variable.empty()) {
diff --git a/Source/cmProcessTools.cxx b/Source/cmProcessTools.cxx
index 34b8df2..8ab8070 100644
--- a/Source/cmProcessTools.cxx
+++ b/Source/cmProcessTools.cxx
@@ -23,10 +23,12 @@ void cmProcessTools::RunProcess(struct cmsysProcess_s* cp, OutputParser* out,
   while ((out || err) &&
          (p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     if (out && p == cmsysProcess_Pipe_STDOUT) {
+      cmsysProcess_DecodeTextOutput(cp, &data, &length);
       if (!out->Process(data, length)) {
         out = CM_NULLPTR;
       }
     } else if (err && p == cmsysProcess_Pipe_STDERR) {
+      cmsysProcess_DecodeTextOutput(cp, &data, &length);
       if (!err->Process(data, length)) {
         err = CM_NULLPTR;
       }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 9740ef7..aeb5471 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -616,6 +616,7 @@ bool cmSystemTools::RunSingleCommand(std::vector<std::string> const& command,
       (captureStdOut || captureStdErr || outputflag != OUTPUT_NONE)) {
     while ((pipe = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR)) >
            0) {
+      cmsysProcess_DecodeTextOutput(cp, &data, &length);
       // Translate NULL characters in the output into valid text.
       // Visual Studio 7 puts these characters in the output of its
       // build process.
@@ -1689,11 +1690,13 @@ int cmSystemTools::WaitForLine(cmsysProcess* process, std::string& line,
       return pipe;
     } else if (pipe == cmsysProcess_Pipe_STDOUT) {
       // Append to the stdout buffer.
+      cmsysProcess_DecodeTextOutput(process, &data, &length);
       std::vector<char>::size_type size = out.size();
       out.insert(out.end(), data, data + length);
       outiter = out.begin() + size;
     } else if (pipe == cmsysProcess_Pipe_STDERR) {
       // Append to the stderr buffer.
+      cmsysProcess_DecodeTextOutput(process, &data, &length);
       std::vector<char>::size_type size = err.size();
       err.insert(err.end(), data, data + length);
       erriter = err.begin() + size;
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 39b03b3..65203c0 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -708,6 +708,8 @@ IF(KWSYS_USE_Process)
   IF(NOT UNIX)
     # Use the Windows implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessWin32.c)
+    SET_PROPERTY(SOURCE ProcessWin32.c APPEND PROPERTY COMPILE_DEFINITIONS
+      KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
   ELSE()
     # Use the UNIX implementation.
     SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessUNIX.c)
diff --git a/Source/kwsys/Process.h.in b/Source/kwsys/Process.h.in
index 96563a2..0c79b47 100644
--- a/Source/kwsys/Process.h.in
+++ b/Source/kwsys/Process.h.in
@@ -67,6 +67,7 @@
 # define kwsysProcess_Execute                   kwsys_ns(Process_Execute)
 # define kwsysProcess_Disown                    kwsys_ns(Process_Disown)
 # define kwsysProcess_WaitForData               kwsys_ns(Process_WaitForData)
+# define kwsysProcess_DecodeTextOutput          kwsys_ns(Process_DecodeTextOutput)
 # define kwsysProcess_Pipes_e                   kwsys_ns(Process_Pipes_e)
 # define kwsysProcess_Pipe_None                 kwsys_ns(Process_Pipe_None)
 # define kwsysProcess_Pipe_STDIN                kwsys_ns(Process_Pipe_STDIN)
@@ -356,6 +357,18 @@ enum kwsysProcess_Pipes_e
 };
 
 /**
+ * Decode pipe's text output from external encoding to internal.
+ *
+ * data   = Must be a pointer to the same data buffer that WaitForData
+            returned.
+ * length = Pointer to the length of data, also must be same as returned
+ *          from WaitForData.
+ *
+ * Returns 1 if data was succesfully decoded or 0 in case of error.
+ */
+kwsysEXPORT int kwsysProcess_DecodeTextOutput(kwsysProcess* cp, char** data, int* length);
+
+/**
  * Block until the child process terminates or the given timeout
  * expires.  If no process is running, returns immediatly.  The
  * argument is:
diff --git a/Source/kwsys/ProcessUNIX.c b/Source/kwsys/ProcessUNIX.c
index b577982..a357b22 100644
--- a/Source/kwsys/ProcessUNIX.c
+++ b/Source/kwsys/ProcessUNIX.c
@@ -1187,6 +1187,12 @@ int kwsysProcess_WaitForData(kwsysProcess* cp, char** data, int* length,
 }
 
 /*--------------------------------------------------------------------------*/
+int kwsysProcess_DecodeTextOutput(kwsysProcess* cp, char** data, int* length)
+{
+  return 1;
+}
+
+/*--------------------------------------------------------------------------*/
 static int kwsysProcessWaitForPipe(kwsysProcess* cp, char** data, int* length,
                                    kwsysProcessWaitData* wd)
 {
diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
index 2b93e69..6424969 100644
--- a/Source/kwsys/ProcessWin32.c
+++ b/Source/kwsys/ProcessWin32.c
@@ -69,6 +69,7 @@ a UNIX-style select system call.
 
 /* The maximum amount to read from a pipe at a time.  */
 #define KWSYSPE_PIPE_BUFFER_SIZE 1024
+#define KWSYSPE_PIPE_ACTUAL_BUFFER_SIZE (KWSYSPE_PIPE_BUFFER_SIZE * 2)
 
 /* Debug output macro.  */
 #if 0
@@ -181,7 +182,7 @@ struct kwsysProcessPipeData_s
   /* ------------- Data managed per call to Execute ------------- */
 
   /* Buffer for data read in this pipe's thread.  */
-  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
+  char DataBuffer[KWSYSPE_PIPE_ACTUAL_BUFFER_SIZE];
 
   /* The length of the data stored in the buffer.  */
   DWORD DataLength;
@@ -319,6 +320,9 @@ struct kwsysProcess_s
   /* Own handles for the child's ends of the pipes in the parent process.
      Used temporarily during process creation.  */
   HANDLE PipeChildStd[3];
+
+  /* Console's active codepage */
+  UINT codepage;
 };
 
 /*--------------------------------------------------------------------------*/
@@ -1645,6 +1649,28 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp, kwsysProcessPipeData* td)
 }
 
 /*--------------------------------------------------------------------------*/
+int kwsysProcess_DecodeTextOutput(kwsysProcess* cp, char** data, int* length)
+{
+  int success = 1;
+  if (cp && data && length && *length > 0 &&
+    cp->codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
+    success = 0;
+    const int wlength = MultiByteToWideChar(cp->codepage, 0, *data, *length, NULL, 0);
+    wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
+    int r = MultiByteToWideChar(cp->codepage, 0, *data, *length, wdata, wlength);
+    if (r > 0) {
+      r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0, wdata, wlength, *data, KWSYSPE_PIPE_ACTUAL_BUFFER_SIZE, NULL, NULL);
+      if (r > 0) {
+        *length = r;
+        success = 1;
+      }
+    }
+    free(wdata);
+  }
+  return success;
+}
+
+/*--------------------------------------------------------------------------*/
 
 /*
   Function executed for each pipe's thread.  Argument is a pointer to
@@ -1761,6 +1787,11 @@ int kwsysProcessInitialize(kwsysProcess* cp)
     }
   }
 
+  cp->codepage = GetConsoleCP();
+  if (!cp->codepage) {
+    cp->codepage = GetACP();
+  }
+
   return 1;
 }
 
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index c84d71f..f3e5a50 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -4637,6 +4637,7 @@ std::string SystemInformationImplementation::RunProcess(std::vector<const char*>
   while( ( static_cast<void>(pipe = kwsysProcess_WaitForData(gp,&data,&length,&timeout)),
            (pipe == kwsysProcess_Pipe_STDOUT || pipe == kwsysProcess_Pipe_STDERR) ) ) // wait for 1s
     {
+      kwsysProcess_DecodeTextOutput(gp, &data, &length);
       buffer.append(data, length);
     }
   kwsysProcess_WaitForExit(gp, 0);
-- 
2.9.0


From davispuh at gmail.com  Thu Jul  7 17:54:04 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Fri,  8 Jul 2016 00:54:04 +0300
Subject: [cmake-developers] [PATCH v4 2/4] Deprecate const char*
	SystemTools::GetEnv function
In-Reply-To: <20160707215406.16180-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
Message-ID: <20160707215406.16180-2-davispuh@gmail.com>

---
 Source/kwsys/SystemTools.hxx.in | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index 8f01e75..f6fc282 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -26,6 +26,16 @@
 # include <unistd.h> // For access permissions for use with access()
 #endif
 
+#if __cplusplus >= 201402L
+# define DEPRECATED [[deprecated]]
+#elif defined(__GNUC__)
+# define DEPRECATED __attribute__ ((deprecated))
+#elif defined(_MSC_VER)
+# define DEPRECATED __declspec(deprecated)
+#else
+# define DEPRECATED
+#endif
+
 // Required for va_list
 #include <stdarg.h>
 // Required for FILE*
@@ -840,8 +850,8 @@ public:
   /**
    * Read an environment variable
    */
-  static const char* GetEnv(const char* key);
-  static const char* GetEnv(const std::string& key);
+  DEPRECATED static const char* GetEnv(const char* key);
+  DEPRECATED static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
   static bool HasEnv(const char* key);
-- 
2.9.0


From davispuh at gmail.com  Thu Jul  7 18:32:17 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Fri,  8 Jul 2016 01:32:17 +0300
Subject: [cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct
	encoding for SystemTools::GetEnv
In-Reply-To: <20160707215406.16180-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
Message-ID: <20160707223217.11825-1-davispuh@gmail.com>

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
instead and encode that.

Also add SystemTools::HasEnv function.
---
 Source/kwsys/SystemTools.cxx    | 80 +++++++++++++++++++++++++++++++++++------
 Source/kwsys/SystemTools.hxx.in |  4 +++
 2 files changed, 74 insertions(+), 10 deletions(-)

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..5bcf0d0 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -406,6 +406,9 @@ struct SystemToolsPathCaseCmp
 class SystemToolsPathCaseMap:
   public std::map<std::string, std::string,
                         SystemToolsPathCaseCmp> {};
+
+class SystemToolsEnvMap :
+    public std::map<std::string,std::string> {};
 #endif
 
 // adds the elements of the env variable path to the arg passed in
@@ -458,7 +461,23 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
 
 const char* SystemTools::GetEnv(const char* key)
 {
-  return getenv(key);
+  const char *v = 0;
+#if defined(_WIN32)
+  std::string env;
+  if (SystemTools::GetEnv(key, env)) {
+    const std::string skey = key;
+    SystemToolsEnvMap::iterator i = EnvMap->find(skey);
+    if (i != EnvMap->end()) {
+      i->second = env;
+    } else {
+      i = EnvMap->insert(SystemToolsEnvMap::value_type(skey, env)).first;
+    }
+    v = i->second.c_str();
+  }
+#else
+  v = getenv(key);
+#endif
+  return v;
 }
 
 const char* SystemTools::GetEnv(const std::string& key)
@@ -468,16 +487,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+    result = Encoding::ToNarrow(wv);
+    return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-    {
+  if (v) {
     result = v;
     return true;
-    }
-  else
-    {
-    return false;
-    }
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -485,6 +509,22 @@ bool SystemTools::GetEnv(const std::string& key, std::string& result)
   return SystemTools::GetEnv(key.c_str(), result);
 }
 
+bool SystemTools::HasEnv(const char* key)
+{
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* v = _wgetenv(wkey.c_str());
+#else
+  const char* v = getenv(key);
+#endif
+  return v != 0;
+}
+
+bool SystemTools::HasEnv(const std::string& key)
+{
+  return SystemTools::HasEnv(key.c_str());
+}
+
 //----------------------------------------------------------------------------
 
 #if defined(__CYGWIN__) || defined(__GLIBC__)
@@ -533,13 +573,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0)
     {
     err = errno;
     }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
     {
     err = errno;
     }
@@ -679,7 +731,12 @@ public:
     static_cast<void>(oldEnv);
     char* newEnv = strdup(env);
     this->insert(newEnv);
+#if defined(_WIN32)
+    const std::wstring wEnv = Encoding::ToWide(newEnv);
+    return _wputenv(wEnv.c_str()) == 0;
+#else
     return putenv(newEnv) == 0;
+#endif
     }
   bool UnPut(const char* env)
     {
@@ -5371,6 +5428,7 @@ static unsigned int SystemToolsManagerCount;
 SystemToolsTranslationMap *SystemTools::TranslationMap;
 #ifdef _WIN32
 SystemToolsPathCaseMap *SystemTools::PathCaseMap;
+SystemToolsEnvMap *SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
 SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
@@ -5421,6 +5479,7 @@ void SystemTools::ClassInitialize()
   SystemTools::TranslationMap = new SystemToolsTranslationMap;
 #ifdef _WIN32
   SystemTools::PathCaseMap = new SystemToolsPathCaseMap;
+  SystemTools::EnvMap = new SystemToolsEnvMap;
 #endif
 #ifdef __CYGWIN__
   SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
@@ -5480,6 +5539,7 @@ void SystemTools::ClassFinalize()
   delete SystemTools::TranslationMap;
 #ifdef _WIN32
   delete SystemTools::PathCaseMap;
+  delete SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
   delete SystemTools::Cyg2Win32Map;
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..8f01e75 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -53,6 +53,7 @@ namespace @KWSYS_NAMESPACE@
 
 class SystemToolsTranslationMap;
 class SystemToolsPathCaseMap;
+class SystemToolsEnvMap;
 
 /** \class SystemToolsManager
  * \brief Use to make sure SystemTools is initialized before it is used
@@ -843,6 +844,8 @@ public:
   static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
+  static bool HasEnv(const char* key);
+  static bool HasEnv(const std::string& key);
 
   /** Put a string into the environment
       of the form var=value */
@@ -989,6 +992,7 @@ private:
   static SystemToolsTranslationMap *TranslationMap;
 #ifdef _WIN32
   static SystemToolsPathCaseMap *PathCaseMap;
+  static SystemToolsEnvMap *EnvMap;
 #endif
 #ifdef __CYGWIN__
   static SystemToolsTranslationMap *Cyg2Win32Map;
-- 
2.9.0


From Tobias.Hunger at qt.io  Fri Jul  8 07:53:42 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Fri, 8 Jul 2016 11:53:42 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <CAMdWP3H0YAEcgmxrVafV43TT=_Z-ZAig3SYEQJaWVovfa1POXA@mail.gmail.com>
References: <1467294716.811.298.camel@qt.io> <57756C41.5070001@kitware.com>
 <1467364292.811.344.camel@qt.io> <nlapmk$239$1@ger.gmane.org>
 <1467620290.846.9.camel@qt.io> <nleskh$qcc$1@ger.gmane.org>,
 <CAMdWP3H0YAEcgmxrVafV43TT=_Z-ZAig3SYEQJaWVovfa1POXA@mail.gmail.com>
Message-ID: <DB5PR0201MB1911ABDFDB6DAE8572AA6032F83C0@DB5PR0201MB1911.eurprd02.prod.outlook.com>


Hi fellow Developers,

I just uploaded a new version of the cmake-capabilities. I would appreciate some input:-)

This version still does parsing of the generator names. Stephen rightfully said that is not nice, which I fully agree with.

But to avoid doing that I will need to create instances of generators and interact with those. Is that both safe and fast to do?

I am a bit afraid that one generator or the other might end up doing some expensive checks on startup or maybe write files somewhere or do similar things I do not expect.

Implemented changes include:

Version reporting:
* Rename "appendix" to "suffix"
* Report "dirty" in the version section separately (information available via macro in cmVersionConfig.h)

Code:
* Do not use auto and range based for loops
* Do not use std::unordered_map directly
* Sprinkle this-> over the code

Generators:
* Hide KDevelop3 generator

Best Regads,
Tobias

________________________________
From: cmake-developers <cmake-developers-bounces at cmake.org> on behalf of Tobias Hunger <tobias.hunger at gmail.com>
Sent: Thursday, July 7, 2016 3:51:52 PM
To: Stephen Kelly
Cc: CMake Developers
Subject: Re: [cmake-developers] cmake -E capabilities

Hello,

On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly <steveire at gmail.com>,
me, Stephen Kelly wrote:
>>> Such a feature would also work with cmake projects if the user chooses to
>>> use the XCode generator on mac or VS generator on Windows (or if someday
>>> we have a multi-config Ninja generator or so).
>>
>> How is a multi-config ninja generator better than just having to build
>> directories next to each other, each with one configuration? You might
>> save a bit of disk space (probably not a lot). Will you save a significant
>> amount of processing time?
>>
>> The one benefit I can think of is switching between configurations will
>> probably be a lot faster. But that is nothing that is done so often that
>> it warrants optimizing for IMHO.
>
> What I have in mind is not optimization. As you say, if this is not needed
> at this point for IDE integration, then we can drop the idea.

I still do not get why this feature exists at all. What is the benefit
of having it? Is it just because xcode supports it, so cmake should
to?

>> Either the clients do not care or they need to know which configurations
>> those are going to be.
>
> This can be retrieved by reading the STRINGS property of the
> CMAKE_BUILD_TYPE cache variable.

Oh, that sounds interesting. I'll need to investigate this:-)

Best Regards,
Tobias
--

Powered by www.kitware.com<http://www.kitware.com>
Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/>
www.kitware.com
Kitware's mission is to create state-of-the-art software products and services in visualization and data processing using advanced quality software methods and ...




Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160708/407cdffa/attachment-0001.html>

From brad.king at kitware.com  Fri Jul  8 09:04:10 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 8 Jul 2016 09:04:10 -0400
Subject: [cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct
 encoding for SystemTools::GetEnv
In-Reply-To: <20160707223217.11825-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707223217.11825-1-davispuh@gmail.com>
Message-ID: <577FA4CA.2050209@kitware.com>

On 07/07/2016 06:32 PM, D?vis Mos?ns wrote:
> On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
> to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
> instead and encode that.
> 
> Also add SystemTools::HasEnv function.

Thanks.  KWSys is maintained externally to CMake so I've ported
this patch over for integration there first.  I split it into
two commits for review and testing here:

 http://review.source.kitware.com/21318
 http://review.source.kitware.com/21319

Once integrated there I can update it in CMake and then move
on to more of your patches.

Thanks,
-Brad


From davispuh at gmail.com  Fri Jul  8 09:26:41 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Fri, 8 Jul 2016 16:26:41 +0300
Subject: [cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct
 encoding for SystemTools::GetEnv
In-Reply-To: <577FA4CA.2050209@kitware.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707223217.11825-1-davispuh@gmail.com>
 <577FA4CA.2050209@kitware.com>
Message-ID: <CAOE4rSyWp3mgW=jPW=W72vNSn638oCeRWGzEvMi=6vEqL4kUNQ@mail.gmail.com>

2016-07-08 16:04 GMT+03:00 Brad King <brad.king at kitware.com>:
> On 07/07/2016 06:32 PM, D?vis Mos?ns wrote:
>> On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
>> to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
>> instead and encode that.
>>
>> Also add SystemTools::HasEnv function.
>
> Thanks.  KWSys is maintained externally to CMake so I've ported
> this patch over for integration there first.  I split it into
> two commits for review and testing here:
>
>  http://review.source.kitware.com/21318
>  http://review.source.kitware.com/21319
>
> Once integrated there I can update it in CMake and then move
> on to more of your patches.
>

Great! Thanks!

From davispuh at gmail.com  Sat Jul  9 22:12:28 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Sun, 10 Jul 2016 05:12:28 +0300
Subject: [cmake-developers] [PATCH v4] For consoles output on Windows use
	our own std::streambuf
In-Reply-To: <20160706191213.16242-5-davispuh@gmail.com>
References: <20160706191213.16242-5-davispuh@gmail.com>
Message-ID: <20160710021230.10618-1-davispuh@gmail.com>

Currently Microsoft's C++ libraries implementation of std::cout/cerr
can't output Unicode characters but only ASCII or ANSI if locale is set
so we implement and use our own ConsoleBuf which can output Unicode
characters to console and it doesn't matter what locale or console's
codepage is set.
---
 CMakeLists.txt                 |   1 +
 Source/cmakemain.cxx           |  27 ++++
 Source/kwsys/CMakeLists.txt    |   6 +-
 Source/kwsys/ConsoleBuf.hxx.in | 282 +++++++++++++++++++++++++++++++++++++++++
 bootstrap                      |   1 +
 5 files changed, 316 insertions(+), 1 deletion(-)
 create mode 100644 Source/kwsys/ConsoleBuf.hxx.in

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ae5990e..792b5a5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -258,6 +258,7 @@ macro (CMAKE_BUILD_UTILITIES)
   set(KWSYS_USE_MD5 1)
   set(KWSYS_USE_Process 1)
   set(KWSYS_USE_CommandLineArguments 1)
+  set(KWSYS_USE_ConsoleBuf 1)
   set(KWSYS_HEADER_ROOT ${CMake_BINARY_DIR}/Source)
   set(KWSYS_INSTALL_DOC_DIR "${CMAKE_DOC_DIR}")
   add_subdirectory(Source/kwsys)
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index 521a5bf..95eb154 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -26,6 +26,7 @@
 #include "cmake.h"
 #include "cmcmd.h"
 #include <cmsys/Encoding.hxx>
+#include <cmsys/ConsoleBuf.hxx>
 
 #ifdef CMAKE_BUILD_WITH_CMAKE
 static const char* cmDocumentationName[][2] = {
@@ -153,6 +154,22 @@ static void cmakemainProgressCallback(const char* m, float prog,
 
 int main(int ac, char const* const* av)
 {
+#if defined(_WIN32)
+  // Replace streambuf so we can output Unicode to console
+  cmsys::ConsoleBuf *cbufio = CM_NULLPTR;
+  cmsys::ConsoleBuf *cbuferr = CM_NULLPTR;
+  std::streambuf *coutbuf = std::cout.rdbuf();
+  std::streambuf *cerrbuf = std::cerr.rdbuf();
+  try {
+    cbufio = new cmsys::ConsoleBuf();
+    coutbuf = std::cout.rdbuf(cbufio);
+    cbuferr = new cmsys::ConsoleBuf(true);
+    cerrbuf = std::cerr.rdbuf(cbuferr);
+  } catch (const std::runtime_error& ex) {
+    std::cerr << "Failed to create ConsoleBuf!" << std::endl
+              << ex.what() << std::endl;
+  };
+#endif
   cmsys::Encoding::CommandLineArguments args =
     cmsys::Encoding::CommandLineArguments::Main(ac, av);
   ac = args.argc();
@@ -171,6 +188,16 @@ int main(int ac, char const* const* av)
 #ifdef CMAKE_BUILD_WITH_CMAKE
   cmDynamicLoader::FlushCache();
 #endif
+#if defined(_WIN32)
+  if (cbufio) {
+    delete cbufio;
+    std::cout.rdbuf(coutbuf);
+  }
+  if (cbuferr) {
+    delete cbuferr;
+    std::cerr.rdbuf(cerrbuf);
+  }
+#endif
   return ret;
 }
 
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 65203c0..33a97e6 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -123,6 +123,7 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
   SET(KWSYS_USE_FStream 1)
   SET(KWSYS_USE_String 1)
   SET(KWSYS_USE_SystemInformation 1)
+  SET(KWSYS_USE_ConsoleBuf 1)
 ENDIF()
 
 # Enforce component dependencies.
@@ -154,6 +155,9 @@ ENDIF()
 IF(KWSYS_USE_FStream)
   SET(KWSYS_USE_Encoding 1)
 ENDIF()
+IF(KWSYS_USE_ConsoleBuf)
+  SET(KWSYS_USE_Encoding 1)
+ENDIF()
 
 # Setup the large file support default.
 IF(KWSYS_LFS_DISABLE)
@@ -668,7 +672,7 @@ SET(KWSYS_HXX_FILES Configure String
 # Add selected C++ classes.
 SET(cppclasses
   Directory DynamicLoader Encoding Glob RegularExpression SystemTools
-  CommandLineArguments IOStream FStream SystemInformation
+  CommandLineArguments IOStream FStream SystemInformation ConsoleBuf
   )
 FOREACH(cpp ${cppclasses})
   IF(KWSYS_USE_${cpp})
diff --git a/Source/kwsys/ConsoleBuf.hxx.in b/Source/kwsys/ConsoleBuf.hxx.in
new file mode 100644
index 0000000..4ee37dd
--- /dev/null
+++ b/Source/kwsys/ConsoleBuf.hxx.in
@@ -0,0 +1,282 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+#define @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+
+#include <@KWSYS_NAMESPACE@/Configure.hxx>
+#include <@KWSYS_NAMESPACE@/Encoding.hxx>
+#include <string>
+#include <cstring>
+#include <sstream>
+#include <streambuf>
+#include <stdexcept>
+
+#if defined(_WIN32)
+#  include <windows.h>
+#  if __cplusplus >= 201103L
+#    include <system_error>
+#  endif
+#endif
+
+namespace @KWSYS_NAMESPACE@
+{
+#if defined(_WIN32)
+
+  template<class CharT, class Traits = std::char_traits<CharT> >
+  class @KWSYS_NAMESPACE at _EXPORT BasicConsoleBuf : public std::basic_streambuf<CharT, Traits> {
+    public:
+      typedef typename Traits::int_type int_type;
+      typedef typename Traits::char_type char_type;
+
+      BasicConsoleBuf(const bool err = false) :
+        flush_on_newline(true),
+        input_pipe_codepage(0),
+        output_pipe_codepage(0),
+        input_file_codepage(CP_UTF8),
+        output_file_codepage(CP_UTF8),
+        m_consolesCodepage(0)
+      {
+        m_hInput = ::GetStdHandle(STD_INPUT_HANDLE);
+        checkHandle(true, "STD_INPUT_HANDLE");
+        setActiveCodepage(true, "STD_INPUT_HANDLE");
+        m_hOutput = err ? ::GetStdHandle(STD_ERROR_HANDLE) :
+                          ::GetStdHandle(STD_OUTPUT_HANDLE);
+        checkHandle(false, err ? "STD_ERROR_HANDLE" : "STD_OUTPUT_HANDLE");
+        setActiveCodepage(false, err ? "STD_ERROR_HANDLE" : "STD_OUTPUT_HANDLE");
+        _setg();
+        _setp();
+      }
+
+      ~BasicConsoleBuf() {
+        sync();
+      }
+
+    protected:
+      virtual int sync() {
+        bool success = true;
+        if (m_hInput && m_isConsoleInput && ::FlushConsoleInputBuffer(m_hInput) == 0) {
+          success = false;
+        }
+        if (m_hOutput && !m_obuffer.empty()) {
+          const std::wstring wbuffer = getBuffer(m_obuffer);
+          if (m_isConsoleOutput) {
+            DWORD charsWritten;
+            success = ::WriteConsoleW(m_hOutput, wbuffer.c_str(), (DWORD)wbuffer.size(), &charsWritten, NULL) == 0 ? false : true;
+          } else {
+            DWORD bytesWritten;
+            std::string buffer;
+            success = encodeOutputBuffer(wbuffer, buffer);
+            if (success) {
+              success = ::WriteFile(m_hOutput, buffer.c_str(), (DWORD)buffer.size(), &bytesWritten, NULL) == 0 ? false : true;
+            }
+          }
+        }
+        m_ibuffer.clear();
+        m_obuffer.clear();
+        _setg();
+        _setp();
+        return success ? 0 : -1;
+      }
+
+      virtual int_type underflow() {
+        if (this->gptr() >= this->egptr()) {
+          if (!m_hInput) {
+            _setg(true);
+            return Traits::eof();
+          }
+          if (m_isConsoleInput) {
+            wchar_t wbuffer[128];
+            DWORD charsRead;
+            if (::ReadConsoleW(m_hInput, wbuffer, ARRAYSIZE(wbuffer) - 1, &charsRead, NULL) == 0 || charsRead == 0) {
+              _setg(true);
+              return Traits::eof();
+            }
+            wbuffer[charsRead] = L'\0';
+            setBuffer(wbuffer, m_ibuffer);
+          } else {
+            std::wstring totalBuffer;
+            std::wstring wbuffer;
+            char buffer[128];
+            DWORD bytesRead;
+            while (::ReadFile(m_hInput, buffer, ARRAYSIZE(buffer) - 1, &bytesRead, NULL) == 0) {
+              if (::GetLastError() == ERROR_MORE_DATA) {
+                buffer[bytesRead] = '\0';
+                if (decodeInputBuffer(buffer, wbuffer)) {
+                  totalBuffer += wbuffer;
+                  continue;
+                }
+              }
+              _setg(true);
+              return Traits::eof();
+            }
+            buffer[bytesRead] = '\0';
+            if (!decodeInputBuffer(buffer, wbuffer)) {
+              _setg(true);
+              return Traits::eof();
+            }
+            totalBuffer += wbuffer;
+            setBuffer(totalBuffer, m_ibuffer);
+          }
+          _setg();
+        }
+        return Traits::to_int_type(*this->gptr());
+      }
+
+      virtual int_type overflow(int_type ch = Traits::eof()) {
+        if (!Traits::eq_int_type(ch, Traits::eof())) {
+          char_type chr = Traits::to_char_type(ch);
+          m_obuffer += chr;
+          if ((flush_on_newline && Traits::eq(chr, '\n')) || Traits::eq_int_type(ch, 0x00)) {
+            sync();
+          }
+          return ch;
+        }
+        sync();
+        return Traits::eof();
+      }
+
+    public:
+      bool flush_on_newline;
+      UINT input_pipe_codepage;
+      UINT output_pipe_codepage;
+      UINT input_file_codepage;
+      UINT output_file_codepage;
+
+    private:
+      HANDLE m_hInput;
+      HANDLE m_hOutput;
+      std::basic_string<char_type> m_ibuffer;
+      std::basic_string<char_type> m_obuffer;
+      bool m_isConsoleInput;
+      bool m_isConsoleOutput;
+      UINT m_activeInputCodepage;
+      UINT m_activeOutputCodepage;
+      UINT m_consolesCodepage;
+      void checkHandle(bool input, std::string handleName) {
+        if ((input && m_hInput == INVALID_HANDLE_VALUE) || (!input && m_hOutput == INVALID_HANDLE_VALUE)) {
+          std::string errmsg = "GetStdHandle(" + handleName + ") returned INVALID_HANDLE_VALUE";
+#if __cplusplus >= 201103L
+          throw std::system_error(::GetLastError(), std::system_category(), errmsg);
+#else
+          throw std::runtime_error(errmsg);
+#endif
+        }
+      }
+      UINT getConsolesCodepage() {
+        if (!m_consolesCodepage) {
+          m_consolesCodepage = GetConsoleCP();
+          if (!m_consolesCodepage) {
+            m_consolesCodepage = GetACP();
+          }
+        }
+        return m_consolesCodepage;
+      }
+      void setActiveCodepage(bool input, std::string handleName) {
+        std::ostringstream errmsg;
+        DWORD ft;
+        switch (ft = GetFileType(input ? m_hInput : m_hOutput)) {
+          case FILE_TYPE_DISK:
+            if (input) {
+               m_isConsoleInput = false;
+               m_activeInputCodepage = input_file_codepage;
+            } else {
+               m_isConsoleOutput = false;
+               m_activeOutputCodepage = output_file_codepage;
+            };
+            break;
+          case FILE_TYPE_CHAR:
+            if (input) {
+              m_isConsoleInput = true;
+            } else {
+              m_isConsoleOutput = true;
+            };
+            break;
+          case FILE_TYPE_PIPE:
+            if (input) {
+              m_isConsoleInput = false;
+              m_activeInputCodepage = input_pipe_codepage;
+            } else {
+              m_isConsoleOutput = false;
+              m_activeOutputCodepage = output_pipe_codepage;
+            };
+            break;
+          default:
+            errmsg << "GetFileType for " << handleName << " returned unknown file type " << ft;
+#if __cplusplus >= 201103L
+            throw std::system_error(::GetLastError(), std::system_category(), errmsg.str());
+#else
+            throw std::runtime_error(errmsg.str());
+#endif
+        }
+        if (input && !m_isConsoleInput && m_activeInputCodepage == 0) {
+           m_activeInputCodepage = getConsolesCodepage();
+        } else if (!input && !m_isConsoleOutput && m_activeOutputCodepage == 0) {
+           m_activeOutputCodepage = getConsolesCodepage();
+        }
+      }
+      void _setg(bool empty = false) {
+        if (!empty) {
+          this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        } else {
+          this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        }
+      }
+      void _setp() {
+        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
+      }
+      bool encodeOutputBuffer(const std::wstring wbuffer, std::string &buffer) {
+        const int length = WideCharToMultiByte(m_activeOutputCodepage, 0, wbuffer.c_str(), (int)wbuffer.size(), NULL, 0, NULL, NULL);
+        char *buf = new char[length + 1];
+        const bool success = WideCharToMultiByte(m_activeOutputCodepage, 0, wbuffer.c_str(), (int)wbuffer.size(), buf, length, NULL, NULL) > 0 ? true : false;
+        buf[length] = '\0';
+        buffer = buf;
+        delete[] buf;
+        return success;
+      }
+      bool decodeInputBuffer(const char *buffer, std::wstring &wbuffer) {
+        int actualCodepage = m_activeInputCodepage;
+        const char BOM_UTF8[] = { char(0xEF), char(0xBB), char(0xBF) };
+        if (std::memcmp(buffer, BOM_UTF8, sizeof(BOM_UTF8)) == 0) {
+          // PowerShell uses UTF-8 with BOM for pipes
+          actualCodepage = CP_UTF8;
+          buffer += sizeof(BOM_UTF8);
+        }
+        const int wlength = MultiByteToWideChar(actualCodepage, 0, buffer, -1, NULL, 0);
+        wchar_t *wbuf = new wchar_t[wlength];
+        const bool success = MultiByteToWideChar(actualCodepage, 0, buffer, -1, wbuf, wlength) > 0 ? true : false;
+        wbuffer = wbuf;
+        delete[] wbuf;
+        return success;
+      }
+      std::wstring getBuffer(const std::basic_string<char> buffer) {
+        return Encoding::ToWide(buffer);
+      }
+      std::wstring getBuffer(const std::basic_string<wchar_t> buffer) {
+        return buffer;
+      }
+      void setBuffer(const std::wstring wbuffer, std::basic_string<char> &target) {
+        target = Encoding::ToNarrow(wbuffer);
+      }
+      void setBuffer(const std::wstring wbuffer, std::basic_string<wchar_t> &target) {
+        target = wbuffer;
+      }
+
+  }; // BasicConsoleBuf class
+
+  typedef BasicConsoleBuf<char>    ConsoleBuf;
+  typedef BasicConsoleBuf<wchar_t> WConsoleBuf;
+
+#endif
+} // KWSYS_NAMESPACE
+
+#endif
+
diff --git a/bootstrap b/bootstrap
index ad0c8ec..0411c64 100755
--- a/bootstrap
+++ b/bootstrap
@@ -365,6 +365,7 @@ KWSYS_CXX_SOURCES="\
   SystemTools"
 
 KWSYS_FILES="\
+  ConsoleBuf.hxx \
   Directory.hxx \
   Encoding.h \
   Encoding.hxx \
-- 
2.9.0


From foss at grueninger.de  Sun Jul 10 09:35:24 2016
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=)
Date: Sun, 10 Jul 2016 15:35:24 +0200
Subject: [cmake-developers] Don't enclose CMake version to generated files
Message-ID: <57824F1C.3030006@grueninger.de>

Dear CMake develoers,
I just updated openSuse's CMake package. We have a patch, that removes
the CMake version from generated files. This is aiming to reduce the
re-publishing of generated files. Please find the current patch attached.
What do you think, can we get this somehow upstreamed? Or are you
opposed to the general idea and keep the CMake version in the files?

Bye
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-version-in-generated-files.patch
Type: text/x-patch
Size: 4143 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160710/0182bdfc/attachment.bin>

From rleigh at codelibre.net  Sun Jul 10 14:21:34 2016
From: rleigh at codelibre.net (Roger Leigh)
Date: Sun, 10 Jul 2016 18:21:34 +0000
Subject: [cmake-developers] [patch] FindICU: New module
Message-ID: <5782922E.6030009@codelibre.net>

ICU is a longstanding staple library for C++ Unicode functionality which 
is used as a dependency by many common C++ libraries and programs.

The change is here 
https://gitlab.kitware.com/cmake/cmake/merge_requests/32 and I've also 
merged this into next for testing.

This change also includes the appropriate documentation additions, plus 
unit tests.


Regards,
Roger

From rleigh at codelibre.net  Sun Jul 10 14:23:06 2016
From: rleigh at codelibre.net (Roger Leigh)
Date: Sun, 10 Jul 2016 18:23:06 +0000
Subject: [cmake-developers] [patch] Fix variable naming in FindTIFF unit test
Message-ID: <5782928A.3080301@codelibre.net>

Straightforward renaming, in 
https://gitlab.kitware.com/cmake/cmake/merge_requests/33 which is also 
merged into next for testing.


Regards,
Roger

From Harry at codexdigital.com  Mon Jul 11 07:50:32 2016
From: Harry at codexdigital.com (Harry Mallon)
Date: Mon, 11 Jul 2016 11:50:32 +0000
Subject: [cmake-developers] Some CPackRPM Debug print is printing without
	DEBUG On
Message-ID: <44F314A7-530C-4AD5-B5CB-410330BF76D5@codexdigital.com>

I get this line printed a lot even without CPACK_RPM_PACKAGE_DEBUG turned on.

"CPackRPM:Debug: Adding /usr/lib/systemd;/usr/lib/systemd/system;/usr/lib/systemd/system-preset;/usr/lib/udev;/usr/lib/udev/rules.d;/usr/etc;/etc/security;/etc/security/limits.d to builtin omit list."

Patch attached

Harry


Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E harry at codexdigital.com | T +44 203 7000 989
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-sure-CPackRPM-Debug-print-about-Auto-Filelist-o.patch
Type: application/octet-stream
Size: 1144 bytes
Desc: 0001-Make-sure-CPackRPM-Debug-print-about-Auto-Filelist-o.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160711/70fc591a/attachment.obj>

From domen.vrankar at gmail.com  Mon Jul 11 08:13:16 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 11 Jul 2016 14:13:16 +0200
Subject: [cmake-developers] Some CPackRPM Debug print is printing
 without DEBUG On
In-Reply-To: <44F314A7-530C-4AD5-B5CB-410330BF76D5@codexdigital.com>
References: <44F314A7-530C-4AD5-B5CB-410330BF76D5@codexdigital.com>
Message-ID: <CAKgx6BL3=hwX9VocZ+TzWp1B_frQXD4ALz1KvRFfdmY7D2q7ag@mail.gmail.com>

2016-07-11 13:50 GMT+02:00 Harry Mallon <Harry at codexdigital.com>:
> I get this line printed a lot even without CPACK_RPM_PACKAGE_DEBUG turned on.
>
> "CPackRPM:Debug: Adding /usr/lib/systemd;/usr/lib/systemd/system;/usr/lib/systemd/system-preset;/usr/lib/udev;/usr/lib/udev/rules.d;/usr/etc;/etc/security;/etc/security/limits.d to builtin omit list."
>
> Patch attached

Provided patchi disables both debug message as well as
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST functionality. That if statement
should not be changed and instead a new if statement wrapping only
message should be added.

Regards,
Domen

From Harry at codexdigital.com  Mon Jul 11 08:59:09 2016
From: Harry at codexdigital.com (Harry Mallon)
Date: Mon, 11 Jul 2016 12:59:09 +0000
Subject: [cmake-developers] Some CPackRPM Debug print is printing
 without DEBUG On
In-Reply-To: <CAKgx6BL3=hwX9VocZ+TzWp1B_frQXD4ALz1KvRFfdmY7D2q7ag@mail.gmail.com>
References: <44F314A7-530C-4AD5-B5CB-410330BF76D5@codexdigital.com>
 <CAKgx6BL3=hwX9VocZ+TzWp1B_frQXD4ALz1KvRFfdmY7D2q7ag@mail.gmail.com>
Message-ID: <A3E72601-48B0-4BFF-A5CD-FFA02B4F893F@codexdigital.com>

Doh. Less haste more speed. Thanks. Patch 2.

H


Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E harry at codexdigital.com | T +44 203 7000 989
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-sure-CPackRPM-Debug-print-about-Auto-Filelist-o.patch
Type: application/octet-stream
Size: 1237 bytes
Desc: 0001-Make-sure-CPackRPM-Debug-print-about-Auto-Filelist-o.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160711/30e9908e/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160711/30e9908e/attachment.txt>

From ben.boeckel at kitware.com  Mon Jul 11 09:22:37 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 11 Jul 2016 09:22:37 -0400
Subject: [cmake-developers] Don't enclose CMake version to generated
	files
In-Reply-To: <57824F1C.3030006@grueninger.de>
References: <57824F1C.3030006@grueninger.de>
Message-ID: <20160711132237.GA14511@megas.kitware.com>

On Sun, Jul 10, 2016 at 15:35:24 +0200, Christoph Gr?ninger wrote:
> I just updated openSuse's CMake package. We have a patch, that removes
> the CMake version from generated files. This is aiming to reduce the
> re-publishing of generated files. Please find the current patch attached.
> What do you think, can we get this somehow upstreamed? Or are you
> opposed to the general idea and keep the CMake version in the files?

Thanks!

> Enclosing the cmake version will cause a republish of generated files

What do you mean by "republish"? Do you mean "cause a rebuild"? The
files generated by CMake should, generally, not be put into source
control. If you mean "rebuild", only the header generation code needs to
really not put the version into the file. The version in generated
build.ninja, Makefiles, and CPack-related files shouldn't be a problem.

--Ben

From foss at grueninger.de  Mon Jul 11 11:17:03 2016
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=C3=BCninger?=)
Date: Mon, 11 Jul 2016 17:17:03 +0200 (CEST)
Subject: [cmake-developers] Don't enclose CMake version to generated
 files
In-Reply-To: <20160711132237.GA14511@megas.kitware.com>
References: <57824F1C.3030006@grueninger.de>
 <20160711132237.GA14511@megas.kitware.com>
Message-ID: <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>

Hi Ben,
this comes from the open build system, which is the system used by
openSuse to generate the packages. If the CMake version is updated,
which happens quite often, the generated files are altered and the
packages are rebuild, repackaged and republished.
Without the version number in the generated files, it wouldn't
happen.

Bye
Christoph

From Harry at codexdigital.com  Mon Jul 11 11:32:18 2016
From: Harry at codexdigital.com (Harry Mallon)
Date: Mon, 11 Jul 2016 15:32:18 +0000
Subject: [cmake-developers] CpackRPM doesn't escape filenames
Message-ID: <C39EE0D8-7B37-4178-AB4D-3E22600337CA@codexdigital.com>

When using CPackRPM my filenames in auto generated RPM SPEC look like "/usr/share/foo/bar10%.xml" when the "%" symbol (which is in the filename should be escaped to "%%".

See: http://www.rpm.org/wiki/PackagerDocs/Spec (Shell Globbing of %files Section).

Harry

Harry Mallon

CODEX | Software Engineer

60 Poland Street | London | England | W1F 7NT

E harry at codexdigital.com<mailto:harry at codexdigital.com> | T +44 203 7000 989<callto:+44%20203%207000%20989>

Website<www.codexdigital.com> | Facebook<https://www.facebook.com/codexdigital> | Twitter<http://twitter.com/codexdigital>

[http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]<http://www.codexdigital.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160711/f087dc8b/attachment-0001.html>

From ben.boeckel at kitware.com  Mon Jul 11 11:46:05 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 11 Jul 2016 11:46:05 -0400
Subject: [cmake-developers] Don't enclose CMake version to generated
	files
In-Reply-To: <2024674013.311603.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
References: <57824F1C.3030006@grueninger.de>
 <20160711132237.GA14511@megas.kitware.com>
 <2024674013.311603.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
Message-ID: <20160711154605.GA19965@megas.kitware.com>

On Mon, Jul 11, 2016 at 17:16:22 +0200, Christoph Gr?ninger wrote:
> this comes from the open build system, which is the system used by
> openSuse to generate the packages. If the CMake version is updated,
> which happens quite often, the generated files are altered and the
> packages are rebuild, repackaged and republished.
> Without the version number in the generated files, it wouldn't
> happen.

Why do the generated makefiles and ninja files cause this problem? Are
they packaged too? I grant that the export header one makes sense, but
the others not as much (and certainly not the Qt IFW file since I would
be surprised to see a Linux distro using it).

In any case, such information would be nice to have in the commit
message.

Thanks,

--Ben

From brad.king at kitware.com  Mon Jul 11 12:02:46 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 11 Jul 2016 12:02:46 -0400
Subject: [cmake-developers] Don't enclose CMake version to generated
	files
In-Reply-To: <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
References: <57824F1C.3030006@grueninger.de>
 <20160711132237.GA14511@megas.kitware.com>
 <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
Message-ID: <324a5e97-e8a5-4784-d1c0-4325861b1904@kitware.com>

On 07/11/2016 11:17 AM, Christoph Gr?ninger wrote:
> this comes from the open build system, which is the system used by
> openSuse to generate the packages. If the CMake version is updated,
> which happens quite often, the generated files are altered and the
> packages are rebuild, repackaged and republished.
> Without the version number in the generated files, it wouldn't
> happen.

I think dropping the version number from the various Export generators
should be sufficient for this.  The generated build system files like
build.ninja should not affect the results of package installation.

I've applied the "export" parts of the patch:

 Do not place CMake version in export files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c376c5bc

Thanks,
-Brad


From foss at grueninger.de  Mon Jul 11 12:57:56 2016
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=C3=BCninger?=)
Date: Mon, 11 Jul 2016 18:57:56 +0200 (CEST)
Subject: [cmake-developers] Don't enclose CMake version to generated
 files
In-Reply-To: <324a5e97-e8a5-4784-d1c0-4325861b1904@kitware.com>
References: <57824F1C.3030006@grueninger.de>
 <20160711132237.GA14511@megas.kitware.com>
 <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
 <324a5e97-e8a5-4784-d1c0-4325861b1904@kitware.com>
Message-ID: <1566592661.320239.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>

Hi Brad, hi Ben,

> I've applied the "export" parts of the patch:
> 
>  Do not place CMake version in export files
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c376c5bc

Hu, that was fast. Thank you. I wanted to discuss whether openSuse
or CMake should change. I'll apply the patch to our package and
check whether everybody is satisfied.

Bye
Christoph

From irwin at beluga.phys.uvic.ca  Mon Jul 11 13:01:13 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 11 Jul 2016 10:01:13 -0700 (PDT)
Subject: [cmake-developers] Don't enclose CMake version to generated
 files
In-Reply-To: <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
References: <57824F1C.3030006@grueninger.de>
 <20160711132237.GA14511@megas.kitware.com>
 <930814258.311664.c6640691-5ec5-4e39-bef4-976488e8ea11.open-xchange@com4.strato.de>
Message-ID: <alpine.DEB.2.11.1607110944450.5398@enira.zlyna.ubzr>

On 2016-07-11 17:17+0200 Christoph Gr?ninger wrote:

> Hi Ben,
> this comes from the open build system, which is the system used by
> openSuse to generate the packages. If the CMake version is updated,
> which happens quite often, the generated files are altered and the
> packages are rebuild, repackaged and republished.
> Without the version number in the generated files, it wouldn't
> happen.

Hi Christoph:

For the use case you describe, shouldn't that rebuild happen to maintain
consistency between the openSuse version of CMake and all the openSuse
packages that are built with CMake? CMake does have a large degree of
backwards compatibility, but it is not perfect so I think the version
does matter.

Another way of saying this is you might want to consider CMake to be
part of the tool chain (like gcc is) where any version difference is
presumably considered to be quite significant and therefore worth a
rebuild of binary packages.  I don't know what openSuse policy is for
gcc version changes, but presumably such changes are heavily
controlled to reduce rebuilds, and openSuse has the option of
following that heavy control of version change policy for CMake
instead of doing what I consider to be a workaround which is patching
CMake to remove version information from the generated results.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From Tobias.Hunger at qt.io  Mon Jul 11 10:13:41 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Mon, 11 Jul 2016 14:13:41 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1467294716.811.298.camel@qt.io>
References: <1467294716.811.298.camel@qt.io>
Message-ID: <1468246418.846.42.camel@qt.io>

Hello Developers,

https://github.com/hunger/CMake/commits/cmake-capabilities

is in a state now that could use another review.

It addresses all the issues that Stephen brought up, with small patches
extending the information reported via GeneratorInfo bit by bit. Only
when all that is in place, the new cmake -E capabilities is added.

This now creates extra generators (all of them), which does not seem to effect
run time of cmake -E capabilities by much on Linux. I have not tested this on
Windows/Mac though as I do not have those platforms handy.

If that is not acceptable, then some string-parsing is going to be necessary.
I'd move that into cmake::GetRegisteredGenerators, where it is more of an
implementation detail than in the code that actually handles the capability
reporting.

Best Regards,
Tobias

-- Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From brad.king at kitware.com  Mon Jul 11 14:10:15 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 11 Jul 2016 14:10:15 -0400
Subject: [cmake-developers] CpackRPM doesn't escape filenames
In-Reply-To: <C39EE0D8-7B37-4178-AB4D-3E22600337CA@codexdigital.com>
References: <C39EE0D8-7B37-4178-AB4D-3E22600337CA@codexdigital.com>
Message-ID: <d25a5046-d1a0-a4df-ec32-bc31caca7aba@kitware.com>

On 07/11/2016 11:32 AM, Harry Mallon wrote:
> When using CPackRPM my filenames in auto generated RPM SPEC
> look like "/usr/share/foo/bar10%.xml" when the "%" symbol
> (which is in the filename should be escaped to "%%".

Thanks.  Please open an issue here:

 https://gitlab.kitware.com/cmake/cmake/issues

Ideally please include a http://sscce.org/ showing how to
reproduce the problem.  Then perhaps it can be adapted as
a test case.

Thanks,
-Brad


From domen.vrankar at gmail.com  Mon Jul 11 14:56:41 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 11 Jul 2016 20:56:41 +0200
Subject: [cmake-developers] Some CPackRPM Debug print is printing
 without DEBUG On
In-Reply-To: <A3E72601-48B0-4BFF-A5CD-FFA02B4F893F@codexdigital.com>
References: <44F314A7-530C-4AD5-B5CB-410330BF76D5@codexdigital.com>
 <CAKgx6BL3=hwX9VocZ+TzWp1B_frQXD4ALz1KvRFfdmY7D2q7ag@mail.gmail.com>
 <A3E72601-48B0-4BFF-A5CD-FFA02B4F893F@codexdigital.com>
Message-ID: <CAKgx6BLst9+r2cbhBSrec_NYQ0_yPx-39ktf1EURUzksv24WuA@mail.gmail.com>

> Doh. Less haste more speed. Thanks. Patch 2.

Pushed to next:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=49df5d480045ea77295825f2968ec57c4146b5d8

Thanks,
Domen

From daniel at pfeifer-mail.de  Tue Jul 12 04:43:52 2016
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Tue, 12 Jul 2016 10:43:52 +0200
Subject: [cmake-developers] QtAutoGenerators output in Ninja
Message-ID: <CANZMcXqAriXBhKReQd+nQSR7C+ttSsLQAU0yEEo7cHsk=tqn7Q@mail.gmail.com>

Hi,

CMake currently puts messages like "Generating moc source" into the
buildlog. This conflicts with the convention "no output == all good".
The messages blend nicely in the colorful output of Unix Makefiles,
but when using the Ninja generator, they create quite some noise.

How can this be improved?
* remove the messages (no output == all good)
* add an option to silence them
* add an option to show them and hide them per default
* ...

Cheers, Daniel

From kfunk at kde.org  Tue Jul 12 06:58:32 2016
From: kfunk at kde.org (Kevin Funk)
Date: Tue, 12 Jul 2016 12:58:32 +0200
Subject: [cmake-developers] QtAutoGenerators output in Ninja
In-Reply-To: <CANZMcXqAriXBhKReQd+nQSR7C+ttSsLQAU0yEEo7cHsk=tqn7Q@mail.gmail.com>
References: <CANZMcXqAriXBhKReQd+nQSR7C+ttSsLQAU0yEEo7cHsk=tqn7Q@mail.gmail.com>
Message-ID: <3859492.pPeGOptmu7@kerberos>

On Tuesday, July 12, 2016 10:43:52 AM CEST Daniel Pfeifer wrote:
> Hi,
> 
> CMake currently puts messages like "Generating moc source" into the
> buildlog. This conflicts with the convention "no output == all good".

+1

> The messages blend nicely in the colorful output of Unix Makefiles,
> but when using the Ninja generator, they create quite some noise.

Indeed.

> How can this be improved?
> * remove the messages (no output == all good)
> * add an option to silence them
> * add an option to show them and hide them per default
> * ...

While it probably still makes sense to have it for Unix Makefiles; can we just 
disable this particular output in case Ninja files are used?

After all it's just a call to `cmake -E cmake_autogen`, right? Can we 
parameterize this call?

Just my 2 ct.

Cheers,
Kevin

> Cheers, Daniel


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160712/22533d99/attachment-0001.sig>

From Harry at codexdigital.com  Tue Jul 12 07:12:21 2016
From: Harry at codexdigital.com (Harry Mallon)
Date: Tue, 12 Jul 2016 11:12:21 +0000
Subject: [cmake-developers] CpackRPM doesn't escape filenames
In-Reply-To: <d25a5046-d1a0-a4df-ec32-bc31caca7aba@kitware.com>
References: <C39EE0D8-7B37-4178-AB4D-3E22600337CA@codexdigital.com>
 <d25a5046-d1a0-a4df-ec32-bc31caca7aba@kitware.com>
Message-ID: <2C77DA5D-0AFF-44EA-99DA-027F071EE372@codexdigital.com>

Hi Brad,

A simple version, which covers the main test case is shown here. The %files list in the auto spec file shows "%dist.txt" when I think it should show "%%dist.txt". Even when I manually changed it to %% it didn't work for me though. Maybe someone who knows RPM better would be able to tell me why. Other cases could also be tested by adding more files (for those who have any of ?|*.\'" in their file names).

----------------------

CMakeLists.txt:

cmake_minimum_required(VERSION 3.5)

set(CPACK_GENERATOR "RPM")

project(Test)
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/%dist.txt" "")

install(FILES
    "${CMAKE_CURRENT_BINARY_DIR}/%dist.txt"
    DESTINATION foo
)

include(CPack)



Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E harry at codexdigital.com | T +44 203 7000 989
> On 11 Jul 2016, at 19:10, Brad King <brad.king at kitware.com> wrote:
>
> On 07/11/2016 11:32 AM, Harry Mallon wrote:
>> When using CPackRPM my filenames in auto generated RPM SPEC
>> look like "/usr/share/foo/bar10%.xml" when the "%" symbol
>> (which is in the filename should be escaped to "%%".
>
> Thanks.  Please open an issue here:
>
> https://gitlab.kitware.com/cmake/cmake/issues
>
> Ideally please include a http://sscce.org/ showing how to
> reproduce the problem.  Then perhaps it can be adapted as
> a test case.
>
> Thanks,
> -Brad
>


From domen.vrankar at gmail.com  Tue Jul 12 10:13:35 2016
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 12 Jul 2016 16:13:35 +0200
Subject: [cmake-developers] CpackRPM doesn't escape filenames
In-Reply-To: <2C77DA5D-0AFF-44EA-99DA-027F071EE372@codexdigital.com>
References: <C39EE0D8-7B37-4178-AB4D-3E22600337CA@codexdigital.com>
 <d25a5046-d1a0-a4df-ec32-bc31caca7aba@kitware.com>
 <2C77DA5D-0AFF-44EA-99DA-027F071EE372@codexdigital.com>
Message-ID: <CAKgx6BK1eTCPxPvUj4rqwvDOMk_7Xx6ZWrwUzVAJvaATvpWo1w@mail.gmail.com>

> A simple version, which covers the main test case is shown here.

Thanks.

> The %files list in the auto spec file shows "%dist.txt" when I think it should show "%%dist.txt". Even when I manually changed it to %% it didn't work for me though. Maybe someone who knows RPM better would be able to tell me why.

CPackRPM uses globbing to find all the files so you can't escape it in
install command (install is executed first and must have valid
filename without any RPM specific escapes, then later on internally
CPackRPM globs for files and escaping should be performed there).

>  Other cases could also be tested by adding more files (for those who have any of ?|*.\'" in their file names).

I'll add some additional tests for these cases as well and see if it breaks.

Thanks,
Domen

From konstantin at podsvirov.pro  Tue Jul 12 18:43:18 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Wed, 13 Jul 2016 01:43:18 +0300
Subject: [cmake-developers] [PATCH] CMake installation improvements
Message-ID: <71651468363398@web20m.yandex.ru>

Hello Brad,

please apply my changes.

--
Regards,
Konstantin Podsvirov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CMake-install-COMPONENT-cmcldeps.patch
Type: text/x-diff
Size: 4075 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160713/bd21b4bf/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-QtIFW-process-USE_LGPL-when-CMake_INSTALL_COMPONENTS.patch
Type: text/x-diff
Size: 1094 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160713/bd21b4bf/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-QtIFW-Don-t-show-component-selection-page-if-it-don-.patch
Type: text/x-diff
Size: 797 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160713/bd21b4bf/attachment-0002.patch>

From davispuh at gmail.com  Tue Jul 12 22:05:33 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed, 13 Jul 2016 05:05:33 +0300
Subject: [cmake-developers] [PATCH v4] Add MinGW support for FStream
In-Reply-To: <20160706191213.16242-7-davispuh@gmail.com>
References: <20160706191213.16242-7-davispuh@gmail.com>
Message-ID: <20160713020533.31222-1-davispuh@gmail.com>

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard
and it's only present for MSVC but it isn't present in libstdc++ (MinGW)
so we implement this functionality using GNU libstdc++ stdio_filebuf
extension and _wfopen function.
---
 CMakeLists.txt              |  14 +++
 Source/kwsys/CMakeLists.txt |   8 ++
 Source/kwsys/FStream.hxx.in | 235 +++++++++++++++++++++++++++++++-------------
 3 files changed, 187 insertions(+), 70 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 792b5a5..b53c6b1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -273,6 +273,20 @@ macro (CMAKE_BUILD_UTILITIES)
     CMAKE_SET_TARGET_FOLDER(${KWSYS_NAMESPACE}TestSharedForward "${kwsys_folder}")
   endif()
 
+  IF(KWSYS_USE_SystemTools)
+    SET(KWSYS_USE_Directory 1)
+    SET(KWSYS_USE_FStream 1)
+    SET(KWSYS_USE_Encoding 1)
+  ENDIF()
+
+  IF(KWSYS_USE_FStream)
+    INCLUDE(CheckIncludeFileCXX)
+    CHECK_INCLUDE_FILE_CXX(ext/stdio_filebuf.h HAVE_EXT_STDIO_FILEBUF_H)
+    IF(HAVE_EXT_STDIO_FILEBUF_H)
+      add_definitions(-DHAVE_EXT_STDIO_FILEBUF_H=1)
+    ENDIF()
+  ENDIF()
+
   #---------------------------------------------------------------------
   # Setup third-party libraries.
   # Everything in the tree should be able to include files from the
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 33a97e6..02ba2db 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -636,6 +636,14 @@ IF(KWSYS_USE_SystemInformation)
   ENDIF()
 ENDIF()
 
+IF(KWSYS_USE_FStream)
+  INCLUDE(CheckIncludeFileCXX)
+  CHECK_INCLUDE_FILE_CXX(ext/stdio_filebuf.h HAVE_EXT_STDIO_FILEBUF_H)
+  IF(HAVE_EXT_STDIO_FILEBUF_H)
+    add_definitions(-DHAVE_EXT_STDIO_FILEBUF_H=1)
+  ENDIF()
+ENDIF()
+
 #-----------------------------------------------------------------------------
 # Choose a directory for the generated headers.
 IF(NOT KWSYS_HEADER_ROOT)
diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in
index 681e4d8..eb911c9 100644
--- a/Source/kwsys/FStream.hxx.in
+++ b/Source/kwsys/FStream.hxx.in
@@ -14,152 +14,247 @@
 
 #include <@KWSYS_NAMESPACE@/Encoding.hxx>
 #include <fstream>
+#if defined(_WIN32)
+#  if !defined(_MSC_VER) && defined(HAVE_EXT_STDIO_FILEBUF_H)
+#    include <ext/stdio_filebuf.h>
+#  elif !defined(_MSC_VER) || _MSC_VER < 1400
+#    pragma message("WARNING: Opening non-ASCII files might fail!")
+#  endif
+#endif
 
 namespace @KWSYS_NAMESPACE@
 {
-#if defined(_MSC_VER) && _MSC_VER >= 1400
+#if defined(_WIN32) && (defined(_MSC_VER) || defined(HAVE_EXT_STDIO_FILEBUF_H))
 # if defined(_NOEXCEPT)
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT _NOEXCEPT
 # else
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT
 # endif
+
+#if defined(_MSC_VER)
+
   template<typename CharType,typename Traits>
   class basic_filebuf : public std::basic_filebuf<CharType,Traits>
   {
+# if _MSC_VER >= 1400
     public:
       typedef std::basic_filebuf<CharType,Traits> my_base_type;
       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
       {
+        const std::wstring wstr = Encoding::ToWide(s);
         return static_cast<basic_filebuf*>(
-          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
+          my_base_type::open(wstr.c_str(), mode)
           );
       }
+# endif
+  };
+
+#else
+
+  inline std::wstring getcmode(const std::ios_base::openmode mode) {
+    std::wstring cmode;
+    bool plus = false;
+    if (mode & std::ios_base::app) {
+      cmode += L"a";
+      plus = mode & std::ios_base::in ? true : false;
+    } else if (mode & std::ios_base::trunc ||
+                (mode & std::ios_base::out && (mode & std::ios_base::in) == 0)) {
+      cmode += L"w";
+      plus = mode & std::ios_base::in ? true : false;
+    } else {
+      cmode += L"r";
+      plus = mode & std::ios_base::out ? true : false;
+    }
+    if (plus) {
+      cmode += L"+";
+    }
+    if (mode & std::ios_base::binary) {
+      cmode += L"b";
+    } else {
+      cmode += L"t";
+    }
+    return cmode;
   };
 
+#endif
+
   template<typename CharType,typename Traits = std::char_traits<CharType> >
-  class basic_ifstream : public std::basic_istream<CharType,Traits>
+  class basic_efilebuf
   {
+    public:
+#if defined(_MSC_VER)
+      typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+#else
+      typedef __gnu_cxx::stdio_filebuf<CharType,Traits> internal_buffer_type;
+#endif
+
+      basic_efilebuf() : file_(0)
+      {
+        buf_ = 0;
+      }
+
+      bool _open(char const *file_name,std::ios_base::openmode mode)
+      {
+        if (is_open() || file_) {
+          return false;
+        }
+#if defined(_MSC_VER)
+        const bool success = buf_->open(file_name,mode) != 0;
+#else
+        const std::wstring wstr = Encoding::ToWide(file_name);
+        bool success = false;
+        std::wstring cmode = getcmode(mode);
+        file_ = _wfopen(wstr.c_str(), cmode.c_str());
+        if (file_) {
+          if (buf_) {
+            delete buf_;
+          }
+          buf_ = new internal_buffer_type(file_, mode);
+          success = true;
+        }
+#endif
+        return success;
+      }
+
+      bool is_open()
+      {
+        if (!buf_) {
+          return false;
+        }
+        return buf_->is_open();
+      }
+
+      bool is_open() const
+      {
+        if (!buf_) {
+          return false;
+        }
+        return buf_->is_open();
+      }
+
+      bool _close()
+      {
+        bool success = false;
+        if (buf_) {
+          success = buf_->close() != 0;
+#if !defined(_MSC_VER)
+          if (file_) {
+            success = fclose(file_) == 0 ? success : false;
+            file_ = 0;
+          }
+#endif
+        }
+        return success;
+      }
+
+      static void _set_state(bool success, std::basic_ios<CharType,Traits> *ios, internal_buffer_type* buf_)
+      {
+#if !defined(_MSC_VER)
+        ios->rdbuf(buf_);
+#endif
+        if (!success) {
+          ios->setstate(std::ios_base::failbit);
+        } else {
+          ios->clear();
+        }
+      }
+
+      ~basic_efilebuf()
+     {
+       if (buf_) {
+         delete buf_;
+       }
+     }
+
+    protected:
+      internal_buffer_type* buf_;
+      FILE *file_;
+  };
+
+template<typename CharType,typename Traits = std::char_traits<CharType> >
+class basic_ifstream : public std::basic_istream<CharType,Traits>,
+                       public basic_efilebuf<CharType,Traits>
+{
+  using basic_efilebuf<CharType,Traits>::is_open;
+
   public:
-    typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+    typedef typename basic_efilebuf<CharType, Traits>::internal_buffer_type internal_buffer_type;
     typedef std::basic_istream<CharType,Traits> internal_stream_type;
 
     basic_ifstream() : internal_stream_type(new internal_buffer_type())
     {
-      buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+      this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
     }
     explicit basic_ifstream(char const *file_name,
                             std::ios_base::openmode mode = std::ios_base::in)
       : internal_stream_type(new internal_buffer_type())
     {
-      buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+      this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
       open(file_name,mode);
     }
+
     void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
     {
-      if(!buf_->open(file_name,mode | std::ios_base::in))
-        {
-        this->setstate(std::ios_base::failbit);
-        }
-      else
-        {
-        this->clear();
-        }
-    }
-    bool is_open()
-    {
-      return buf_->is_open();
-    }
-    bool is_open() const
-    {
-      return buf_->is_open();
+      mode = mode | std::ios_base::in;
+      this->_set_state(this->_open(file_name, mode), this, this->buf_);
     }
+
     void close()
     {
-      if(!buf_->close())
-        {
-        this->setstate(std::ios_base::failbit);
-        }
-      else
-      {
-        this->clear();
-      }
+      this->_set_state(this->_close(), this, this->buf_);
     }
 
     internal_buffer_type *rdbuf() const
     {
-      return buf_;
+      return this->buf_;
     }
 
     ~basic_ifstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
     {
-      buf_->close();
-      delete buf_;
+      close();
     }
-
-  private:
-    internal_buffer_type* buf_;
 };
 
 template<typename CharType,typename Traits = std::char_traits<CharType> >
-class basic_ofstream : public std::basic_ostream<CharType,Traits>
+class basic_ofstream : public std::basic_ostream<CharType,Traits>,
+                       public basic_efilebuf<CharType,Traits>
 {
+  using basic_efilebuf<CharType,Traits>::is_open;
+
   public:
-  typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+  typedef typename basic_efilebuf<CharType, Traits>::internal_buffer_type internal_buffer_type;
   typedef std::basic_ostream<CharType,Traits> internal_stream_type;
 
   basic_ofstream() : internal_stream_type(new internal_buffer_type())
   {
-  buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+    this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
   }
   explicit basic_ofstream(char const *file_name,std::ios_base::openmode mode = std::ios_base::out) :
   internal_stream_type(new internal_buffer_type())
   {
-    buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+    this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
     open(file_name,mode);
   }
   void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::out)
   {
-    if(!buf_->open(file_name,mode | std::ios_base::out))
-    {
-    this->setstate(std::ios_base::failbit);
-    }
-    else
-    {
-    this->clear();
-    }
-  }
-  bool is_open()
-  {
-    return buf_->is_open();
-  }
-  bool is_open() const
-  {
-    return buf_->is_open();
+    mode = mode | std::ios_base::out;
+    this->_set_state(this->_open(file_name, mode), this, this->buf_);
   }
+
   void close()
   {
-    if(!buf_->close())
-      {
-      this->setstate(std::ios_base::failbit);
-      }
-    else
-      {
-      this->clear();
-      }
+    this->_set_state(this->_close(), this, this->buf_);
   }
 
   internal_buffer_type *rdbuf() const
   {
-    return buf_.get();
+    return this->buf_;
   }
+
   ~basic_ofstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
   {
-    buf_->close();
-    delete buf_;
+    close();
   }
-
-  private:
-  internal_buffer_type* buf_;
 };
 
   typedef basic_ifstream<char> ifstream;
-- 
2.9.0


From ben at scumways.com  Tue Jul 12 23:16:46 2016
From: ben at scumways.com (Ben Campbell)
Date: Wed, 13 Jul 2016 15:16:46 +1200
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection (fix
	for issue #16196)
Message-ID: <5785B29E.3060201@scumways.com>

A fix for https://gitlab.kitware.com/cmake/cmake/issues/16196

This is my first attempt at doing anything with CMake, so I'd appreciate 
any feedback on my patch! In particular, the pairs of file()/string() 
commands seem a bit convoluted for extracting strings out of the header 
file - is there a more idiomatic approach?
Also, I'm a bit concerned that they are polluting scope by leaking out 
the GIFMAJ/GIFMIN/GIFREL working variables... how would I improve this?


---
  Modules/FindGIF.cmake | 20 ++++++++++++++++++--
  1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/Modules/FindGIF.cmake b/Modules/FindGIF.cmake
index 7bbb8cf..283a299 100644
--- a/Modules/FindGIF.cmake
+++ b/Modules/FindGIF.cmake
@@ -61,7 +61,8 @@ set(GIF_LIBRARIES ${GIF_LIBRARY})
  # to be always " Version 2.0, " in versions 3.x of giflib.
  # In version 4 the member UserData was added to GifFileType, so we 
check for this
  # one.
-# http://giflib.sourcearchive.com/documentation/4.1.4/files.html
+# Versions after 4.1.6 define GIFLIB_MAJOR, GIFLIB_MINOR, and 
GIFLIB_RELEASE
+# see http://giflib.sourceforge.net/gif_lib.html#compatibility
  if(GIF_INCLUDE_DIR)
    include(${CMAKE_CURRENT_LIST_DIR}/CMakePushCheckState.cmake)
    include(${CMAKE_CURRENT_LIST_DIR}/CheckStructHasMember.cmake)
@@ -71,7 +72,22 @@ if(GIF_INCLUDE_DIR)
    set(CMAKE_REQUIRED_INCLUDES "${GIF_INCLUDE_DIR}")
    CHECK_STRUCT_HAS_MEMBER(GifFileType UserData gif_lib.h 
GIF_GifFileType_UserData )
    if(GIF_GifFileType_UserData)
-    set(GIF_VERSION 4)
+    # OK. So we're version 4 or higher. Check for specific version defines
+    file(STRINGS ${GIF_INCLUDE_DIR}/gif_lib.h GIFMAJ REGEX "^[ 
\t]*#define[ \t]+GIFLIB_MAJOR")
+    string(REGEX REPLACE "^.*GIFLIB_MAJOR ([0-9]+).*$" "\\1" GIFMAJ 
${GIFMAJ})
+    # extract minor version
+    file(STRINGS ${GIF_INCLUDE_DIR}/gif_lib.h GIFMIN REGEX "^[ 
\t]*#define[ \t]+GIFLIB_MINOR")
+    string(REGEX REPLACE "^.*GIFLIB_MINOR ([0-9]+).*$" "\\1" GIFMIN 
${GIFMIN})
+    # point release
+    file(STRINGS ${GIF_INCLUDE_DIR}/gif_lib.h GIFREL REGEX "^[ 
\t]*#define[ \t]+GIFLIB_RELEASE")
+    string(REGEX REPLACE "^.*GIFLIB_RELEASE ([0-9]+).*$" "\\1" GIFREL 
${GIFREL})
+    if(GIFMAJ)
+      # yay - got exact version info
+      set(GIF_VERSION ${GIFMAJ}.${GIFMIN}.${GIFREL})
+    else(GIFMAJ)
+      # couldn't find the defines - assume version 4
+      set(GIF_VERSION 4)
+    endif(GIFMAJ)
    endif()
    CMAKE_POP_CHECK_STATE()
  endif()
-- 
2.7.4

From Lars.Schmertmann at governikus.de  Wed Jul 13 04:18:52 2016
From: Lars.Schmertmann at governikus.de (Schmertmann, Lars)
Date: Wed, 13 Jul 2016 08:18:52 +0000
Subject: [cmake-developers] [CMake 0015749]: Make the URL option of
 ExternalProject_Add to accept lists
Message-ID: <3ec61d13-e84a-0e6e-6d62-4f8519f53052@governikus.de>

Hello there,

I try to continue the work from Andr?.
With the attached patch it is possible to use a list of URLs
but it is still limited to a single path.

I think for a mix of pathes/URLs we need to move a lot of code
from ExternalProject.cmake into ExternalProject-download.cmake.
Maybe it is good to realize this in a new ticket/commit?

Best regards
    Lars Schmertmann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PATCH-Add-support-for-multiple-alternative-URLs.patch
Type: text/x-patch
Size: 4313 bytes
Desc: 0001-PATCH-Add-support-for-multiple-alternative-URLs.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160713/2f515d9f/attachment-0001.bin>

From Tobias.Hunger at qt.io  Wed Jul 13 04:47:18 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Wed, 13 Jul 2016 08:47:18 +0000
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1468246418.846.42.camel@qt.io>
References: <1467294716.811.298.camel@qt.io> <1468246418.846.42.camel@qt.io>
Message-ID: <1468399635.846.47.camel@qt.io>

Ping?

On Mo, 2016-07-11 at 14:13 +0000, Tobias Hunger wrote:
> https://github.com/hunger/CMake/commits/cmake-capabilities
> 
> is in a state now that could use another review.

<snip>

-- Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From DLRdave at aol.com  Wed Jul 13 05:14:58 2016
From: DLRdave at aol.com (David Cole)
Date: Wed, 13 Jul 2016 05:14:58 -0400
Subject: [cmake-developers] [CMake 0015749]: Make the URL option of
 ExternalProject_Add to accept lists
In-Reply-To: <3ec61d13-e84a-0e6e-6d62-4f8519f53052@governikus.de>
References: <3ec61d13-e84a-0e6e-6d62-4f8519f53052@governikus.de>
Message-ID: <CAKME8fFp=UijcmYgn56wpDz7JCVPppiQaaOKS9HY0FLZxTjnng@mail.gmail.com>

Looks like you could also use a list of paths if you express them in
"file://..." form. Local files can also be expressed as URLs.


David C.



On Wed, Jul 13, 2016 at 4:18 AM, Schmertmann, Lars
<Lars.Schmertmann at governikus.de> wrote:
> Hello there,
>
> I try to continue the work from Andr?.
> With the attached patch it is possible to use a list of URLs
> but it is still limited to a single path.
>
> I think for a mix of pathes/URLs we need to move a lot of code
> from ExternalProject.cmake into ExternalProject-download.cmake.
> Maybe it is good to realize this in a new ticket/commit?
>
> Best regards
>     Lars Schmertmann
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

From Lars.Schmertmann at governikus.de  Wed Jul 13 05:35:51 2016
From: Lars.Schmertmann at governikus.de (Schmertmann, Lars)
Date: Wed, 13 Jul 2016 09:35:51 +0000
Subject: [cmake-developers] [CMake 0015749]: Make the URL option of
 ExternalProject_Add to accept lists
In-Reply-To: <CAKME8fFp=UijcmYgn56wpDz7JCVPppiQaaOKS9HY0FLZxTjnng@mail.gmail.com>
References: <3ec61d13-e84a-0e6e-6d62-4f8519f53052@governikus.de>
 <CAKME8fFp=UijcmYgn56wpDz7JCVPppiQaaOKS9HY0FLZxTjnng@mail.gmail.com>
Message-ID: <50b420a5-f68c-de58-27bf-ddc832e6456a@governikus.de>

Thanks for the hint. I removed the ^ to replace
all occurrences and not only the first one.

ExternalProject.cmake, Line 1670:
     string(REGEX REPLACE "^file://" "" url "${url}")

Lars S.



Am 13.07.2016 um 11:14 schrieb David Cole:
> Looks like you could also use a list of paths if you express them in
> "file://..." form. Local files can also be expressed as URLs.
>
>
> David C.
>
>
>
> On Wed, Jul 13, 2016 at 4:18 AM, Schmertmann, Lars
> <Lars.Schmertmann at governikus.de> wrote:
>> Hello there,
>>
>> I try to continue the work from Andr?.
>> With the attached patch it is possible to use a list of URLs
>> but it is still limited to a single path.
>>
>> I think for a mix of pathes/URLs we need to move a lot of code
>> from ExternalProject.cmake into ExternalProject-download.cmake.
>> Maybe it is good to realize this in a new ticket/commit?
>>
>> Best regards
>>      Lars Schmertmann
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-support-for-multiple-alternative-URLs.patch
Type: text/x-patch
Size: 4667 bytes
Desc: 0001-Add-support-for-multiple-alternative-URLs.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160713/8f4d8ef0/attachment.bin>

From brad.king at kitware.com  Wed Jul 13 09:12:31 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 09:12:31 -0400
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1468399635.846.47.camel@qt.io>
References: <1467294716.811.298.camel@qt.io> <1468246418.846.42.camel@qt.io>
 <1468399635.846.47.camel@qt.io>
Message-ID: <b5761459-7be1-730c-df23-2d73206e527f@kitware.com>

On 07/13/2016 04:47 AM, Tobias Hunger wrote:
> Ping?

This is on my todo list.  Sorry I haven't been able to get
to it sooner.

-Brad

From brad.king at kitware.com  Wed Jul 13 09:12:38 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 09:12:38 -0400
Subject: [cmake-developers] QtAutoGenerators output in Ninja
In-Reply-To: <3859492.pPeGOptmu7@kerberos>
References: <CANZMcXqAriXBhKReQd+nQSR7C+ttSsLQAU0yEEo7cHsk=tqn7Q@mail.gmail.com>
 <3859492.pPeGOptmu7@kerberos>
Message-ID: <f497b0ba-f6ad-05b6-4960-4a8c0e89da20@kitware.com>

On 07/12/2016 06:58 AM, Kevin Funk wrote:
>> How can this be improved?
>> * remove the messages (no output == all good)
>> * add an option to silence them
>> * add an option to show them and hide them per default
>> * ...
> 
> While it probably still makes sense to have it for Unix Makefiles; can we just 
> disable this particular output in case Ninja files are used?
> 
> After all it's just a call to `cmake -E cmake_autogen`, right? Can we 
> parameterize this call?

The message could be moved in to the comment field of the custom command
generated for this.  That should cause the Makefile generators to add
an echo for it and the Ninja generator to not show it.

-Brad


From brad.king at kitware.com  Wed Jul 13 09:52:04 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 09:52:04 -0400
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection
 (fix for issue #16196)
In-Reply-To: <5785B29E.3060201@scumways.com>
References: <5785B29E.3060201@scumways.com>
Message-ID: <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>

On 07/12/2016 11:16 PM, Ben Campbell wrote:
> A fix for https://gitlab.kitware.com/cmake/cmake/issues/16196

Thanks!  Here are some comments.

> the pairs of file()/string() 
> commands seem a bit convoluted for extracting strings out of the header 
> file - is there a more idiomatic approach?

You could use a single `file(STRINGS)` call and then use `foreach()` with
the `IN LISTS` mode to iterate through them.  Then use `if(MATCHES)` to
extract the individual parts with the `CMAKE_MATCH_<n>` variables.

> Also, I'm a bit concerned that they are polluting scope by leaking out 
> the GIFMAJ/GIFMIN/GIFREL working variables... how would I improve this?

Prefix the working variables with _GIF_ and then unset() them at the end.

If the version is now expected to work please also update
`Tests/CMakeOnly/AllFindModules/CMakeLists.txt` to check that
a version number is extracted.  In a CMake build tree run
`ctest -R CMakeOnly.AllFindModules -V` to run the test.

Thanks,
-Brad


From brad.king at kitware.com  Wed Jul 13 09:57:37 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 09:57:37 -0400
Subject: [cmake-developers] [CMake 0015749]: Make the URL option of
 ExternalProject_Add to accept lists
In-Reply-To: <50b420a5-f68c-de58-27bf-ddc832e6456a@governikus.de>
References: <3ec61d13-e84a-0e6e-6d62-4f8519f53052@governikus.de>
 <CAKME8fFp=UijcmYgn56wpDz7JCVPppiQaaOKS9HY0FLZxTjnng@mail.gmail.com>
 <50b420a5-f68c-de58-27bf-ddc832e6456a@governikus.de>
Message-ID: <493d2744-07ea-76ce-fe97-e09ca89a2a56@kitware.com>

On 07/13/2016 05:35 AM, Schmertmann, Lars wrote:
> Thanks for the hint.

I've merged to `next` for testing:

 ExternalProject: Add support for multiple alternative URLs
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2eec433f

>>> I think for a mix of pathes/URLs we need to move a lot of code
>>> from ExternalProject.cmake into ExternalProject-download.cmake.
>>> Maybe it is good to realize this in a new ticket/commit?

Yes.  If you're actively working on it then I don't think it needs
a separate issue and can just be added as follow-up work.

Thanks,
-Brad


From brad.king at kitware.com  Wed Jul 13 10:04:49 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 10:04:49 -0400
Subject: [cmake-developers] [PATCH] CMake installation improvements
In-Reply-To: <71651468363398@web20m.yandex.ru>
References: <71651468363398@web20m.yandex.ru>
Message-ID: <6b8b859d-fee0-06e8-13f3-00a0a6082d62@kitware.com>

On 07/12/2016 06:43 PM, Konstantin Podsvirov wrote:
> please apply my changes.

Applied, thanks:

 CMake: install COMPONENT cmcldeps
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ae035a5

 QtIFW: process USE_LGPL when CMake_INSTALL_COMPONENTS
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53992808

 QtIFW: Don't show component selection page if it don't need
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2aadb02f

-Brad


From brad.king at kitware.com  Wed Jul 13 10:15:39 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 13 Jul 2016 10:15:39 -0400
Subject: [cmake-developers] [PATCH v4] Add MinGW support for FStream
In-Reply-To: <20160713020533.31222-1-davispuh@gmail.com>
References: <20160706191213.16242-7-davispuh@gmail.com>
 <20160713020533.31222-1-davispuh@gmail.com>
Message-ID: <59f67ea3-37d7-29a6-9f8c-c38422fb2c54@kitware.com>

On 07/12/2016 10:05 PM, D?vis Mos?ns wrote:
> std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard
> and it's only present for MSVC but it isn't present in libstdc++ (MinGW)
> so we implement this functionality using GNU libstdc++ stdio_filebuf
> extension and _wfopen function.

Thanks.

> +IF(KWSYS_USE_FStream)
> +  INCLUDE(CheckIncludeFileCXX)
> +  CHECK_INCLUDE_FILE_CXX(ext/stdio_filebuf.h HAVE_EXT_STDIO_FILEBUF_H)
> +  IF(HAVE_EXT_STDIO_FILEBUF_H)
> +    add_definitions(-DHAVE_EXT_STDIO_FILEBUF_H=1)
> +  ENDIF()
> +ENDIF()

Please use KWSYS_PLATFORM_CXX_TEST with kwsysPlatformTestsCXX.cxx to
do this check, and then store the result in Configure.hxx so that
KWSys clients do not have to repeat the check.  See the existing
case of KWSYS_STL_HAS_WSTRING for an example.  We could name the
new check KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H.

> -  class basic_ifstream : public std::basic_istream<CharType,Traits>
> +  class basic_efilebuf
[snip]
> +class basic_ifstream : public std::basic_istream<CharType,Traits>,
> +                       public basic_efilebuf<CharType,Traits>

Please split this refactoring out into a preceding commit.

Thanks,
-Brad


From ben at scumways.com  Wed Jul 13 18:59:59 2016
From: ben at scumways.com (Ben Campbell)
Date: Thu, 14 Jul 2016 10:59:59 +1200
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection
 (fix for issue #16196)
In-Reply-To: <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>
References: <5785B29E.3060201@scumways.com>
 <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>
Message-ID: <5786C7EF.6040900@scumways.com>

On 14/07/16 01:52, Brad King wrote:
> On 07/12/2016 11:16 PM, Ben Campbell wrote:
>> A fix for https://gitlab.kitware.com/cmake/cmake/issues/16196
>
> Thanks!  Here are some comments.
[snip]
Cool - very helpful!
I've revised my patch to:
  - only scan the headerfile once
  - update the docs in the comment block
  - unset the scratch variables

> If the version is now expected to work please also update
> `Tests/CMakeOnly/AllFindModules/CMakeLists.txt` to check that
> a version number is extracted.  In a CMake build tree run
> `ctest -R CMakeOnly.AllFindModules -V` to run the test.

The existing GIF test looks like it'll keep working fine, so I've not 
fiddled with the tests at all.

Actually, the tests didn't complete on my machine anyway. Looking at the 
output, I'm pretty sure the GIF part worked.
Here's a very cut-down log of the test output (running the latest cmake 
from git, in situ):

$ bin/ctest -R CMakeOnly.AllFindModules -V | grep -i fail
Guessing configuration NoConfig
268: -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed
268: -- Failed to find all ICU components (missing:  ICU_LIBRARY) (found 
version "55.1")
268: -- Failed to find all Ice components (missing: 
Ice_SLICE2CPP_EXECUTABLE Ice_INCLUDE_DIR Ice_SLICE_DIR Ice_LIBRARY)
268: -- Failed to find XercesC (missing:  XercesC_LIBRARY 
XercesC_INCLUDE_DIR XercesC_VERSION)
268: -- Failed to find XalanC (missing:  XalanC_LIBRARY 
XalanC_INCLUDE_DIR XalanC_VERSION XercesC_FOUND)
268: -- Failed to find XercesC (missing:  XercesC_LIBRARY 
XercesC_INCLUDE_DIR XercesC_VERSION)
268:   CMake failed to configure AllFindModules
1/1 Test #268: CMakeOnly.AllFindModules .........***Failed    8.07 sec
0% tests passed, 1 tests failed out of 1
The following tests FAILED:
	268 - CMakeOnly.AllFindModules (Failed)
Errors while running CTest

Not quite sure what the environment the tests expect - is it just a case 
that I've not got all the expected libraries installed?

Ben.



---
  Modules/FindGIF.cmake | 46 +++++++++++++++++++++++++++++++++++-----------
  1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/Modules/FindGIF.cmake b/Modules/FindGIF.cmake
index 7bbb8cf..d657d83 100644
--- a/Modules/FindGIF.cmake
+++ b/Modules/FindGIF.cmake
@@ -2,12 +2,18 @@
  # FindGIF
  # -------
  #
+# This finds the GIF library (giflib)
  #
+# The module defines the following variables:
  #
-# This module searches giflib and defines GIF_LIBRARIES - libraries to
-# link to in order to use GIF GIF_FOUND, if false, do not try to link
-# GIF_INCLUDE_DIR, where to find the headers GIF_VERSION, reports either
-# version 4 or 3 (for everything before version 4)
+# ``GIF_FOUND``
+#   True if giflib was found
+# ``GIF_LIBRARIES``
+#   Libraries to link to in order to use giflib
+# ``GIF_INCLUDE_DIR``
+#   where to find the headers
+# ``GIF_VERSION``
+#   3, 4 or a full version string (eg 5.1.4) for versions >= 4.1.6
  #
  # The minimum required version of giflib can be specified using the
  # standard syntax, e.g.  find_package(GIF 4)
@@ -29,7 +35,7 @@
  #  License text for the above reference.)

  # Created by Eric Wing.
-# Modifications by Alexander Neundorf
+# Modifications by Alexander Neundorf, Ben Campbell

  find_path(GIF_INCLUDE_DIR gif_lib.h
    HINTS
@@ -61,22 +67,40 @@ set(GIF_LIBRARIES ${GIF_LIBRARY})
  # to be always " Version 2.0, " in versions 3.x of giflib.
  # In version 4 the member UserData was added to GifFileType, so we 
check for this
  # one.
-# http://giflib.sourcearchive.com/documentation/4.1.4/files.html
+# Versions after 4.1.6 define GIFLIB_MAJOR, GIFLIB_MINOR, and 
GIFLIB_RELEASE
+# see http://giflib.sourceforge.net/gif_lib.html#compatibility
  if(GIF_INCLUDE_DIR)
    include(${CMAKE_CURRENT_LIST_DIR}/CMakePushCheckState.cmake)
    include(${CMAKE_CURRENT_LIST_DIR}/CheckStructHasMember.cmake)
    CMAKE_PUSH_CHECK_STATE()
    set(CMAKE_REQUIRED_QUIET ${GIF_FIND_QUIETLY})
-  set(GIF_VERSION 3)
    set(CMAKE_REQUIRED_INCLUDES "${GIF_INCLUDE_DIR}")
-  CHECK_STRUCT_HAS_MEMBER(GifFileType UserData gif_lib.h 
GIF_GifFileType_UserData )
-  if(GIF_GifFileType_UserData)
-    set(GIF_VERSION 4)
+
+  # Check for the specific version defines (>=4.1.6 only)
+  file(STRINGS ${GIF_INCLUDE_DIR}/gif_lib.h _GIF_DEFS REGEX "^[ 
\t]*#define[ \t]+GIFLIB_(MAJOR|MINOR|RELEASE)")
+  if(_GIF_DEFS)
+    # yay - got exact version info
+    string(REGEX REPLACE ".*GIFLIB_MAJOR ([0-9]+).*" "\\1" _GIF_MAJ 
${_GIF_DEFS})
+    string(REGEX REPLACE ".*GIFLIB_MINOR ([0-9]+).*" "\\1" _GIF_MIN 
${_GIF_DEFS})
+    string(REGEX REPLACE ".*GIFLIB_RELEASE ([0-9]+).*" "\\1" _GIF_REL 
${_GIF_DEFS})
+    set(GIF_VERSION ${_GIF_MAJ}.${_GIF_MIN}.${_GIF_REL})
+  else()
+    # use UserData field to sniff version instead
+    CHECK_STRUCT_HAS_MEMBER(GifFileType UserData gif_lib.h 
GIF_GifFileType_UserData )
+    if(GIF_GifFileType_UserData)
+      set(GIF_VERSION 4)
+    else()
+      set(GIF_VERSION 3)
+    endif()
    endif()
+
+  unset(_GIF_MAJ)
+  unset(_GIF_MIN)
+  unset(_GIF_REL)
+  unset(_GIF_DEFS)
    CMAKE_POP_CHECK_STATE()
  endif()

-
  # handle the QUIETLY and REQUIRED arguments and set GIF_FOUND to TRUE if
  # all listed variables are TRUE
  include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-- 
2.7.4



From davispuh at gmail.com  Wed Jul 13 22:17:00 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis?=)
Date: Thu, 14 Jul 2016 05:17:00 +0300
Subject: [cmake-developers] [PATCH v5] SystemTools: Teach GetEnv to use
	correct encoding on Windows
In-Reply-To: <20160707215406.16180-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
Message-ID: <20160714021700.17393-1-davispuh@gmail.com>

From: D?vis Mos?ns <davispuh at gmail.com>

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
instead and encode that.

Change-Id: I8cb91f2386eb0efe3ef0a3132d1603217d710b60
---
 SystemTools.cxx    | 190 +++++++++++++++++++++++++++++++++++++++--------------
 SystemTools.hxx.in |   2 +
 2 files changed, 143 insertions(+), 49 deletions(-)

diff --git a/SystemTools.cxx b/SystemTools.cxx
index db4d7af..79d3b96 100644
--- a/SystemTools.cxx
+++ b/SystemTools.cxx
@@ -388,6 +388,64 @@ class SystemToolsTranslationMap :
 {
 };
 
+/* Order by environment key only (VAR from VAR=VALUE).  */
+#if defined(_WIN32)
+typedef wchar_t envchar;
+struct kwsysEnvCompare
+{
+  bool operator() (const wchar_t* l, const wchar_t* r) const
+    {
+    const wchar_t* leq = wcschr(l, '=');
+    const wchar_t* req = wcschr(r, '=');
+    size_t llen = leq? (leq-l) : wcslen(l);
+    size_t rlen = req? (req-r) : wcslen(r);
+    if(llen == rlen)
+      {
+      return wcsncmp(l,r,llen) < 0;
+      }
+    else
+      {
+      return wcscmp(l,r) < 0;
+      }
+    }
+};
+#else
+typedef char envchar;
+struct kwsysEnvCompare
+{
+  bool operator() (const char* l, const char* r) const
+    {
+    const char* leq = strchr(l, '=');
+    const char* req = strchr(r, '=');
+    size_t llen = leq? (leq-l) : strlen(l);
+    size_t rlen = req? (req-r) : strlen(r);
+    if(llen == rlen)
+      {
+      return strncmp(l,r,llen) < 0;
+      }
+    else
+      {
+      return strcmp(l,r) < 0;
+      }
+    }
+};
+#endif
+
+typedef std::set<const envchar*, kwsysEnvCompare> kwsysEnvSetType;
+
+class kwsysUnPutEnv :
+    public kwsysEnvSetType
+{
+  public:
+  ~kwsysUnPutEnv() {
+    for(kwsysEnvSetType::iterator i = this->begin(); i != this->end(); ++i) {
+      free(const_cast<envchar*>(*i));
+    }
+  }
+};
+
+static kwsysUnPutEnv kwsysUnPutEnvInstance;
+
 #ifdef _WIN32
 struct SystemToolsPathCaseCmp
 {
@@ -406,6 +464,9 @@ struct SystemToolsPathCaseCmp
 class SystemToolsPathCaseMap:
   public std::map<std::string, std::string,
                         SystemToolsPathCaseCmp> {};
+
+class SystemToolsEnvMap :
+    public std::map<std::string,std::string> {};
 #endif
 
 // adds the elements of the env variable path to the arg passed in
@@ -458,7 +519,18 @@ void SystemTools::GetPath(std::vector<std::string>& path, const char* env)
 
 const char* SystemTools::GetEnv(const char* key)
 {
-  return getenv(key);
+  const char *v = 0;
+#if defined(_WIN32)
+  std::string env;
+  if (SystemTools::GetEnv(key, env)) {
+    std::string& menv = (*EnvMap)[key];
+    menv = env;
+    v = menv.c_str();
+  }
+#else
+  v = getenv(key);
+#endif
+  return v;
 }
 
 const char* SystemTools::GetEnv(const std::string& key)
@@ -468,16 +540,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+    result = Encoding::ToNarrow(wv);
+    return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-    {
+  if (v) {
     result = v;
     return true;
-    }
-  else
-    {
-    return false;
-    }
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -534,6 +611,7 @@ static int kwsysUnPutEnv(const std::string& env)
   int err = 0;
   size_t pos = env.find('=');
   size_t const len = pos == env.npos ? env.size() : pos;
+  pos = len;
 # ifdef KWSYS_PUTENV_EMPTY
   size_t const sz = len + 2;
 # else
@@ -547,19 +625,31 @@ static int kwsysUnPutEnv(const std::string& env)
     }
   strncpy(buf, env.c_str(), len);
 # ifdef KWSYS_PUTENV_EMPTY
-  buf[len] = '=';
-  buf[len+1] = 0;
-  if(putenv(buf) < 0)
-    {
-    err = errno;
-    }
+  buf[pos] = '=';
+  pos++;
+# endif
+  buf[pos] = 0;
+# if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  wchar_t *newbuf = wcsdup(wbuf.c_str());
+  std::pair<kwsysEnvSetType::iterator,bool> val = kwsysUnPutEnvInstance.insert(newbuf);
+  const int r = _wputenv(*val.first);
 # else
-  buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+  char* newbuf = strdup(buf);
+  std::pair<kwsysEnvSetType::iterator,bool> val = kwsysUnPutEnvInstance.insert(newbuf);
+  const int r = putenv(*val.first);
+# endif
+  if (!val.second) {
+    free(newbuf);
+  }
+# ifdef KWSYS_PUTENV_EMPTY
+  if(r < 0)
+# else
+  if(r < 0 && errno != EINVAL)
+# endif
     {
     err = errno;
     }
-# endif
   if(buf != local_buf)
     {
     free(buf);
@@ -639,49 +729,33 @@ bool SystemTools::UnPutEnv(const std::string& env)
 #  pragma warning disable 444 /* base has non-virtual destructor */
 # endif
 
-/* Order by environment key only (VAR from VAR=VALUE).  */
-struct kwsysEnvCompare
-{
-  bool operator() (const char* l, const char* r) const
-    {
-    const char* leq = strchr(l, '=');
-    const char* req = strchr(r, '=');
-    size_t llen = leq? (leq-l) : strlen(l);
-    size_t rlen = req? (req-r) : strlen(r);
-    if(llen == rlen)
-      {
-      return strncmp(l,r,llen) < 0;
-      }
-    else
-      {
-      return strcmp(l,r) < 0;
-      }
-    }
-};
-
-class kwsysEnv: public std::set<const char*, kwsysEnvCompare>
+class kwsysEnv: public kwsysEnvSetType
 {
   class Free
   {
-    const char* Env;
+    const envchar* Env;
   public:
-    Free(const char* env): Env(env) {}
-    ~Free() { free(const_cast<char*>(this->Env)); }
+    Free(const envchar* env): Env(env) {}
+    ~Free() { free(const_cast<envchar*>(this->Env)); }
   };
 public:
-  typedef std::set<const char*, kwsysEnvCompare> derived;
   ~kwsysEnv()
     {
-    for(derived::iterator i = this->begin(); i != this->end(); ++i)
+    for(kwsysEnvSetType::iterator i = this->begin(); i != this->end(); ++i)
       {
+#if defined(_WIN32)
+      const std::string s = Encoding::ToNarrow(*i);
+      kwsysUnPutEnv(s.c_str());
+#else
       kwsysUnPutEnv(*i);
-      free(const_cast<char*>(*i));
+#endif
+      free(const_cast<envchar*>(*i));
       }
     }
-  const char* Release(const char* env)
+  const envchar* Release(const envchar* env)
     {
-    const char* old = 0;
-    derived::iterator i = this->find(env);
+    const envchar* old = 0;
+    kwsysEnvSetType::iterator i = this->find(env);
     if(i != this->end())
       {
       old = *i;
@@ -691,15 +765,30 @@ public:
     }
   bool Put(const char* env)
     {
-    Free oldEnv(this->Release(env));
-    static_cast<void>(oldEnv);
+#if defined(_WIN32)
+    const std::wstring wEnv = Encoding::ToWide(env);
+    wchar_t* newEnv = wcsdup(wEnv.c_str());
+#else
     char* newEnv = strdup(env);
+#endif
+    Free oldEnv(this->Release(newEnv));
+    static_cast<void>(oldEnv);
+#if defined(_WIN32)
+    this->insert(newEnv);
+    return _wputenv(newEnv) == 0;
+#else
     this->insert(newEnv);
     return putenv(newEnv) == 0;
+#endif
     }
   bool UnPut(const char* env)
     {
+#if defined(_WIN32)
+    const std::wstring wEnv = Encoding::ToWide(env);
+    Free oldEnv(this->Release(wEnv.c_str()));
+#else
     Free oldEnv(this->Release(env));
+#endif
     static_cast<void>(oldEnv);
     return kwsysUnPutEnv(env) == 0;
     }
@@ -5387,6 +5476,7 @@ static unsigned int SystemToolsManagerCount;
 SystemToolsTranslationMap *SystemTools::TranslationMap;
 #ifdef _WIN32
 SystemToolsPathCaseMap *SystemTools::PathCaseMap;
+SystemToolsEnvMap *SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
 SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
@@ -5437,6 +5527,7 @@ void SystemTools::ClassInitialize()
   SystemTools::TranslationMap = new SystemToolsTranslationMap;
 #ifdef _WIN32
   SystemTools::PathCaseMap = new SystemToolsPathCaseMap;
+  SystemTools::EnvMap = new SystemToolsEnvMap;
 #endif
 #ifdef __CYGWIN__
   SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
@@ -5496,6 +5587,7 @@ void SystemTools::ClassFinalize()
   delete SystemTools::TranslationMap;
 #ifdef _WIN32
   delete SystemTools::PathCaseMap;
+  delete SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
   delete SystemTools::Cyg2Win32Map;
diff --git a/SystemTools.hxx.in b/SystemTools.hxx.in
index c9b18b7..8f01e75 100644
--- a/SystemTools.hxx.in
+++ b/SystemTools.hxx.in
@@ -53,6 +53,7 @@ namespace @KWSYS_NAMESPACE@
 
 class SystemToolsTranslationMap;
 class SystemToolsPathCaseMap;
+class SystemToolsEnvMap;
 
 /** \class SystemToolsManager
  * \brief Use to make sure SystemTools is initialized before it is used
@@ -991,6 +992,7 @@ private:
   static SystemToolsTranslationMap *TranslationMap;
 #ifdef _WIN32
   static SystemToolsPathCaseMap *PathCaseMap;
+  static SystemToolsEnvMap *EnvMap;
 #endif
 #ifdef __CYGWIN__
   static SystemToolsTranslationMap *Cyg2Win32Map;
-- 
2.9.0


From brad.king at kitware.com  Thu Jul 14 10:44:56 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 10:44:56 -0400
Subject: [cmake-developers] cmake -E capabilities
In-Reply-To: <1468246418.846.42.camel@qt.io>
References: <1467294716.811.298.camel@qt.io> <1468246418.846.42.camel@qt.io>
Message-ID: <75c78a2b-aaac-bead-3982-6e904e57c592@kitware.com>

On 07/11/2016 10:13 AM, Tobias Hunger wrote:
> https://github.com/hunger/CMake/commits/cmake-capabilities
> 
> is in a state now that could use another review.

Thanks.  I've applied the infrastructure update commits after
making a few minor fixes and merged to `next` for testing:

 Make CMake version suffix available to code
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a077b5d

 Make CMake version dirty state available to code
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af0e1cd4

 cmGlobalGeneratorFactory: Use CM_OVERRIDE for all derived classes
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43a68a6d

 CMake: Report whether generators support platforms
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4db08807

Please rebase the rest on those, at least once they are in `master`.

> This now creates extra generators (all of them), which does not seem to effect
> run time of cmake -E capabilities by much on Linux. I have not tested this on
> Windows/Mac though as I do not have those platforms handy.
> 
> If that is not acceptable, then some string-parsing is going to be necessary.
> I'd move that into cmake::GetRegisteredGenerators, where it is more of an
> implementation detail than in the code that actually handles the capability
> reporting.

The extra generator registration currently adds only the name and
a pointer to the `New` function as meta-data.  One could expand that
to provide a whole "extra generator factory" object that has method
that calls `New` as well as other meta-data that we need for the
capabilities query.

Thanks,
-Brad


From kornel at lyx.org  Thu Jul 14 13:13:38 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 19:13:38 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
Message-ID: <4981247.f4JczbOElL@amd64>

I have 2 compilers installed. The attached minimal CMakeLists.txt example shows everything OK if
using the compiler at standard place.

-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11
-- Configuring done
-- Generating done
-- Build files have been written to: /usr2/kornel/tmp/cmake

But setting for alternative compiler (on clean build dir)
	env{CXX} => /usr/local/gcc6.1/bin/g++
	env{CC} =>  /usr/local/gcc6.1/bin/gcc
I get following output:

-- The C compiler identification is GNU 6.1.0
-- The CXX compiler identification is GNU 6.1.0
-- Check for working C compiler: /usr/local/gcc6.1/bin/gcc
-- Check for working C compiler: /usr/local/gcc6.1/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/gcc6.1/bin/g++
-- Check for working CXX compiler: /usr/local/gcc6.1/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11
-- Configuring done
-- Generating done
-- Build files have been written to: /usr2/kornel/tmp/cmake

I expected here "-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=c++14".

My cmake version is "cmake version 3.6.20160714-ga6bd0"

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/2c27d9ed/attachment.sig>

From brad.king at kitware.com  Thu Jul 14 13:35:06 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 13:35:06 -0400
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <4981247.f4JczbOElL@amd64>
References: <4981247.f4JczbOElL@amd64>
Message-ID: <187dcbbd-0bc8-c4c3-f804-2842addd40f3@kitware.com>

On 07/14/2016 01:13 PM, Kornel Benko wrote:
> -- The CXX compiler identification is GNU 6.1.0
> -- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11
> I expected here "-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=c++14".

That is the option for C++11 with extensions.  See
CMAKE_CXX14_EXTENSION_COMPILE_OPTION for C++14 with extensions.
Both of these are internal table entries for CMake's generators
and not meant for direct use by projects.

What are you actually trying to do?

-Brad


From irwin at beluga.phys.uvic.ca  Thu Jul 14 13:32:31 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 14 Jul 2016 10:32:31 -0700 (PDT)
Subject: [cmake-developers] CMP0065 warning not supressed when --trace used
Message-ID: <alpine.DEB.2.11.1607140921320.5398@enira.zlyna.ubzr>

Hi Chuck:

I am addressing this mostly to you because you are the author of
CMP0065 which has the special property that by default it does not
warn when the policy is not set.  However, I find it does warn when
--trace is set which I am fairly sure is a (minor) bug.

Please take a look at the attached CMakeLists.txt file
which is a self-contained simple test project that demonstrates
the described issue with CMP0065 and --trace.  For this project the policy is not
set because of

cmake_minimum_required(VERSION 3.3.2 FATAL_ERROR)

And indeed normal use of cmake (version 3.5.2) gives no warning for
CMP0065 as advertised by the CMP0065 documentation.

However, on my Linux platform (Debian Jessie with cmake-3.5.2 which I
built with the bootstrap method) if you use the cmake --trace option you do get the following
warning message (after a whole bunch of other messages from the
--trace option).

-- Configuring done
CMake Warning (dev) in CMakeLists.txt:
   Policy CMP0065 is not set: Do not add flags to export symbols from
   executables without the ENABLE_EXPORTS target property.  Run "cmake
   --help-policy CMP0065" for policy details.  Use the cmake_policy command to
   set the policy and suppress this warning.

   For compatibility with older versions of CMake, additional flags may be
   added to export symbols on all executables regardless of thier
   ENABLE_EXPORTS property.
This warning is for project developers.  Use -Wno-dev to suppress it.

First there is an extremely minor but still irritating message content
bug here where you should change "thier" (in the third last line) to
"their".

More seriously, I am pretty sure that the --trace option should not
change warnings policy this way, i.e., this is a bug in --trace or a
bug in the way that CMP0065 implements the supression of the warning
by default.  If you have any difficulty confirming this issue with the
attached CMakeLists.txt and CMake-3.5.2 (or presumably later) please
get back to me.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/49a6b78c/attachment.txt>

From brad.king at kitware.com  Thu Jul 14 13:49:18 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 13:49:18 -0400
Subject: [cmake-developers] CMP0065 warning not supressed when --trace
 used
In-Reply-To: <alpine.DEB.2.11.1607140921320.5398@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1607140921320.5398@enira.zlyna.ubzr>
Message-ID: <477f41f4-e461-5ca7-6359-936699fbde6c@kitware.com>

On 07/14/2016 01:32 PM, Alan W. Irwin wrote:
> I am addressing this mostly to you because you are the author of
> CMP0065 which has the special property that by default it does not
> warn when the policy is not set.  However, I find it does warn when
> --trace is set which I am fairly sure is a (minor) bug.

This is documented behavior:

 https://cmake.org/cmake/help/v3.6/variable/CMAKE_POLICY_WARNING_CMPNNNN.html
 "running cmake(1) with the --debug-output, --trace, or --trace-expand option
  will also enable the warning."

The idea is that tracing is a verbose debug mode so all policies
warn if they are not set.  Add -DCMAKE_POLICY_WARNING_CMP0065=OLD
to disable the warning.

> should change "thier" (in the third last line) to "their".

Recently fixed:

 Fix typos.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56608618

-Brad


From brad.king at kitware.com  Thu Jul 14 13:52:07 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 13:52:07 -0400
Subject: [cmake-developers] CMP0065 warning not supressed when --trace
 used
In-Reply-To: <477f41f4-e461-5ca7-6359-936699fbde6c@kitware.com>
References: <alpine.DEB.2.11.1607140921320.5398@enira.zlyna.ubzr>
 <477f41f4-e461-5ca7-6359-936699fbde6c@kitware.com>
Message-ID: <43d1a4dd-06b6-9b1f-1c63-7656bbde477b@kitware.com>

On 07/14/2016 01:49 PM, Brad King wrote:
> Add -DCMAKE_POLICY_WARNING_CMP0065=OLD to disable the warning.

Sorry, I meant `-DCMAKE_POLICY_DEFAULT_CMP0065=OLD`:

 https://cmake.org/cmake/help/v3.6/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html

-Brad


From kornel at lyx.org  Thu Jul 14 13:59:52 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 19:59:52 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <187dcbbd-0bc8-c4c3-f804-2842addd40f3@kitware.com>
References: <4981247.f4JczbOElL@amd64>
 <187dcbbd-0bc8-c4c3-f804-2842addd40f3@kitware.com>
Message-ID: <6897682.PAFVxPuaT8@amd64>

Am Donnerstag, 14. Juli 2016 um 13:35:06, schrieb Brad King <brad.king at kitware.com>
> On 07/14/2016 01:13 PM, Kornel Benko wrote:
> > -- The CXX compiler identification is GNU 6.1.0
> > -- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11
> > I expected here "-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=c++14".
> 
> That is the option for C++11 with extensions.  See
> CMAKE_CXX14_EXTENSION_COMPILE_OPTION for C++14 with extensions.
> Both of these are internal table entries for CMake's generators
> and not meant for direct use by projects.
> 
> What are you actually trying to do?
> 
> -Brad

I was trying to compile lyx with QT5.7.
The effect was, that the compilation failed. Searching for a reason I found that the flags in the flag.cmake files were mismatched.

Here one example:
	
	# CMAKE generated file: DO NOT EDIT!
	# Generated by "Unix Makefiles" Generator, CMake Version 3.6

	# compile CXX with /usr/local/gcc6.1/bin/g++
	CXX_FLAGS = -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing -O0 -g3 -D_DEBUG   -DBOOST_USER_CONFIG="<config.h>" -fPIC --std=gnu++11

...

Therefore I started searching, where the extra ' --std=gnu++11' came from, and found it in Modules/Compiler/GNU-CXX.cmake.

To verify, I made the output of this variable.
To be clear, I did not want to do anything with the variable CMAKE_CXX14_EXTENSION_COMPILE_OPTION.

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/7c7ebe84/attachment.sig>

From brad.king at kitware.com  Thu Jul 14 14:36:43 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 14:36:43 -0400
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <6897682.PAFVxPuaT8@amd64>
References: <4981247.f4JczbOElL@amd64>
 <187dcbbd-0bc8-c4c3-f804-2842addd40f3@kitware.com> <6897682.PAFVxPuaT8@amd64>
Message-ID: <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com>

On 07/14/2016 01:59 PM, Kornel Benko wrote:
> I was trying to compile lyx with QT5.7.
> ...
> found that the flags in the flag.cmake files were mismatched.
> 
> Therefore I started searching, where the extra ' --std=gnu++11' came
> from, and found it in Modules/Compiler/GNU-CXX.cmake.

It appears there but only in a table.  Other settings are required
to get the table entry to be used.  See the CXX_STANDARD target
property:

 https://cmake.org/cmake/help/v3.6/prop_tgt/CXX_STANDARD.html

Unless you or the project is setting that (perhaps via the
CMAKE_CXX_STANDARD variable) then CMake won't add any flags.

In lyx I see the

 development/cmake/modules/FindCXX11Compiler.cmake

source file that adds such flags.  Please ask them about it.

-Brad


From brad.king at kitware.com  Thu Jul 14 14:39:18 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 14:39:18 -0400
Subject: [cmake-developers] [PATCH v5] SystemTools: Teach GetEnv to use
 correct encoding on Windows
In-Reply-To: <20160714021700.17393-1-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160714021700.17393-1-davispuh@gmail.com>
Message-ID: <b2104cce-d7d5-5e8a-77af-74acf3e3b1e7@kitware.com>

On 07/13/2016 10:17 PM, D?vis wrote:
> On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded
> to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)
> instead and encode that.

Thanks.  Based on that I've constructed a revised topic for KWSys:

 http://review.source.kitware.com/21318

-Brad


From kornel at lyx.org  Thu Jul 14 14:45:37 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 20:45:37 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com>
References: <4981247.f4JczbOElL@amd64> <6897682.PAFVxPuaT8@amd64>
 <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com>
Message-ID: <5673194.Ee0ShTN0f5@amd64>

Am Donnerstag, 14. Juli 2016 um 14:36:43, schrieb Brad King <brad.king at kitware.com>
> On 07/14/2016 01:59 PM, Kornel Benko wrote:
> > I was trying to compile lyx with QT5.7.
> > ...
> > found that the flags in the flag.cmake files were mismatched.
> > 
> > Therefore I started searching, where the extra ' --std=gnu++11' came
> > from, and found it in Modules/Compiler/GNU-CXX.cmake.
> 
> It appears there but only in a table.  Other settings are required
> to get the table entry to be used.  See the CXX_STANDARD target
> property:
> 
>  https://cmake.org/cmake/help/v3.6/prop_tgt/CXX_STANDARD.html
> 
> Unless you or the project is setting that (perhaps via the
> CMAKE_CXX_STANDARD variable) then CMake won't add any flags.
> 
> In lyx I see the
> 
>  development/cmake/modules/FindCXX11Compiler.cmake

No, this file is only used for QT4.
The new cmake-files from QT5.7 are somehow responsible that this happens.
If I compile with QT5.6 (which also has files like Qt5CoreConfig.cmake) no such problem occurs.

> source file that adds such flags.  Please ask them about it.

I know, I am one of the creators. But, as already said, this is not the case here.

> -Brad

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/70d90eac/attachment.sig>

From irwin at beluga.phys.uvic.ca  Thu Jul 14 14:46:36 2016
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 14 Jul 2016 11:46:36 -0700 (PDT)
Subject: [cmake-developers] CMP0065 warning not supressed when --trace
 used
In-Reply-To: <477f41f4-e461-5ca7-6359-936699fbde6c@kitware.com>
References: <alpine.DEB.2.11.1607140921320.5398@enira.zlyna.ubzr>
 <477f41f4-e461-5ca7-6359-936699fbde6c@kitware.com>
Message-ID: <alpine.DEB.2.11.1607141138530.32122@enira.zlyna.ubzr>

On 2016-07-14 13:49-0400 Brad King wrote:

> On 07/14/2016 01:32 PM, Alan W. Irwin wrote:
>> I am addressing this mostly to you because you are the author of
>> CMP0065 which has the special property that by default it does not
>> warn when the policy is not set.  However, I find it does warn when
>> --trace is set which I am fairly sure is a (minor) bug.
>
> This is documented behavior:
>
> https://cmake.org/cmake/help/v3.6/variable/CMAKE_POLICY_WARNING_CMPNNNN.html
> "running cmake(1) with the --debug-output, --trace, or --trace-expand option
>  will also enable the warning."

I should have followed the obvious link in
<https://cmake.org/cmake/help/v3.5/policy/CMP0065.html#policy:CMP0065>
to the above URL.  Sorry for that noise.

>> should change "thier" (in the third last line) to "their".
>
> Recently fixed:
>
> Fix typos.
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56608618

Glad that Felix Geyer spotted this and fixed it last weekend.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Thu Jul 14 14:47:24 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 14:47:24 -0400
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection
 (fix for issue #16196)
In-Reply-To: <5786C7EF.6040900@scumways.com>
References: <5785B29E.3060201@scumways.com>
 <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>
 <5786C7EF.6040900@scumways.com>
Message-ID: <d8595c89-332c-a90d-cfe8-9e890612e161@kitware.com>

On 07/13/2016 06:59 PM, Ben Campbell wrote:
> I've revised my patch to:

Thanks.  Please use `git format-patch` and then attach it.
The inline patch was corrupted and does not apply.

> 1/1 Test #268: CMakeOnly.AllFindModules .........***Failed    8.07 sec
> 
> Not quite sure what the environment the tests expect - is it just a case 
> that I've not got all the expected libraries installed?

It doesn't expect any specific environment.  It is just testing that
all find modules can complete whether the packages are found or not.
The "Failed to find" lines are not a problem.  Other output may
show a real "CMake Error" though.

-Brad


From kornel at lyx.org  Thu Jul 14 14:48:07 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 20:48:07 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com>
References: <4981247.f4JczbOElL@amd64> <6897682.PAFVxPuaT8@amd64>
 <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com>
Message-ID: <4480427.ESX4NFbJ5B@amd64>

Am Donnerstag, 14. Juli 2016 um 14:36:43, schrieb Brad King <brad.king at kitware.com>
> In lyx I see the
> 
>  development/cmake/modules/FindCXX11Compiler.cmake

I had to reread.
Yes, I know this file too. There is set the '-std=c++14'. But I am asking about '-std=gnu++11'.

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/f806bf93/attachment.sig>

From brad.king at kitware.com  Thu Jul 14 15:27:00 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 15:27:00 -0400
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <5673194.Ee0ShTN0f5@amd64>
References: <4981247.f4JczbOElL@amd64> <6897682.PAFVxPuaT8@amd64>
 <5251c5ea-77f5-77ac-d67a-3b3c2c31aae5@kitware.com> <5673194.Ee0ShTN0f5@amd64>
Message-ID: <5a51253d-f3a7-3b30-da47-bb25571b5e38@kitware.com>

On 07/14/2016 02:48 PM, Kornel Benko wrote:
> I am asking about '-std=gnu++11'.
On 07/14/2016 02:45 PM, Kornel Benko wrote:
> The new cmake-files from QT5.7 are somehow responsible that this happens.

The file `lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake` in Qt 5.7 contains:

  set_property(TARGET Qt5::Core PROPERTY INTERFACE_COMPILE_FEATURES cxx_decltype)

This tells CMake that dependents of this library need to be compiled as
at least C++11.  This causes `-std=gnu++11` to be added automatically.

What you can do is not add your own flag and instead do

 set(CMAKE_CXX_STANDARD 14)

or set the CXX_STANDARD property of specific targets.  That tells CMake
to build as C++14 so it will add -std=gnu++14.  If you don't want the
extensions then also set

 set(CMAKE_CXX_EXTENSIONS OFF)

Relevant docs:

 https://cmake.org/cmake/help/v3.6/manual/cmake-compile-features.7.html
 https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_STANDARD.html
 https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_EXTENSIONS.html

-Brad

From kornel at lyx.org  Thu Jul 14 15:59:03 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 21:59:03 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <5a51253d-f3a7-3b30-da47-bb25571b5e38@kitware.com>
References: <4981247.f4JczbOElL@amd64> <5673194.Ee0ShTN0f5@amd64>
 <5a51253d-f3a7-3b30-da47-bb25571b5e38@kitware.com>
Message-ID: <2483844.1KoVq1bcBx@amd64>

Am Donnerstag, 14. Juli 2016 um 15:27:00, schrieb Brad King <brad.king at kitware.com>
> On 07/14/2016 02:48 PM, Kornel Benko wrote:
> > I am asking about '-std=gnu++11'.
> On 07/14/2016 02:45 PM, Kornel Benko wrote:
> > The new cmake-files from QT5.7 are somehow responsible that this happens.
> 
> The file `lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake` in Qt 5.7 contains:
> 
>   set_property(TARGET Qt5::Core PROPERTY INTERFACE_COMPILE_FEATURES cxx_decltype)
> 
> This tells CMake that dependents of this library need to be compiled as
> at least C++11.  This causes `-std=gnu++11` to be added automatically.

Thanks Brad, that was what I was searching for.

> What you can do is not add your own flag and instead do
> 
>  set(CMAKE_CXX_STANDARD 14)
> 
> or set the CXX_STANDARD property of specific targets.  That tells CMake
> to build as C++14 so it will add -std=gnu++14.  If you don't want the
> extensions then also set
> 
>  set(CMAKE_CXX_EXTENSIONS OFF)l

I did this, as it seemed least invasive.
But now, instead of '-std=gnu++1' I got '-std=c++11' which is not better.
Of course, since QT5.7 explicitly requires   C++11 features, we don't need C++14.

> Relevant docs:
> 
>  https://cmake.org/cmake/help/v3.6/manual/cmake-compile-features.7.html
>  https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_STANDARD.html
>  https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_EXTENSIONS.html
> 
> -Brad

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/fb7ea695/attachment-0001.sig>

From brad.king at kitware.com  Thu Jul 14 16:06:17 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 14 Jul 2016 16:06:17 -0400
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <2483844.1KoVq1bcBx@amd64>
References: <4981247.f4JczbOElL@amd64> <5673194.Ee0ShTN0f5@amd64>
 <5a51253d-f3a7-3b30-da47-bb25571b5e38@kitware.com> <2483844.1KoVq1bcBx@amd64>
Message-ID: <cac921fd-9976-e1a4-8d7b-5a6e89f9798f@kitware.com>

On 07/14/2016 03:59 PM, Kornel Benko wrote:
>> What you can do is not add your own flag and instead do
>>
>>  set(CMAKE_CXX_STANDARD 14)
>>  set(CMAKE_CXX_EXTENSIONS OFF)
> 
> I did this, as it seemed least invasive.
> But now, instead of '-std=gnu++1' I got '-std=c++11' which is not better.
> Of course, since QT5.7 explicitly requires   C++11 features, we don't need C++14.

I don't quite follow here.  What flag to you want to get?
Don't add your own flag explicitly.  Some combination of
the above settings can get the flag you need.

-Brad


From kornel at lyx.org  Thu Jul 14 16:41:07 2016
From: kornel at lyx.org (Kornel Benko)
Date: Thu, 14 Jul 2016 22:41:07 +0200
Subject: [cmake-developers] Wrong cxx-extension flags
In-Reply-To: <cac921fd-9976-e1a4-8d7b-5a6e89f9798f@kitware.com>
References: <4981247.f4JczbOElL@amd64> <2483844.1KoVq1bcBx@amd64>
 <cac921fd-9976-e1a4-8d7b-5a6e89f9798f@kitware.com>
Message-ID: <5717346.FFN6dRJE5e@amd64>

Am Donnerstag, 14. Juli 2016 um 16:06:17, schrieb Brad King <brad.king at kitware.com>
> On 07/14/2016 03:59 PM, Kornel Benko wrote:
> >> What you can do is not add your own flag and instead do
> >>
> >>  set(CMAKE_CXX_STANDARD 14)
> >>  set(CMAKE_CXX_EXTENSIONS OFF)
> > 
> > I did this, as it seemed least invasive.
> > But now, instead of '-std=gnu++1' I got '-std=c++11' which is not better.
> > Of course, since QT5.7 explicitly requires   C++11 features, we don't need C++14.
> 
> I don't quite follow here.  What flag to you want to get?

I meant we don't need to test for c++14.

> Don't add your own flag explicitly.  Some combination of
> the above settings can get the flag you need.

I have to stick also with older cmake versions, so bear with me.

Nonetheless, I tested some combinations already, and it all looks good.

> -Brad

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160714/875c8434/attachment.sig>

From ben at scumways.com  Thu Jul 14 18:31:13 2016
From: ben at scumways.com (Ben Campbell)
Date: Fri, 15 Jul 2016 10:31:13 +1200
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection
 (fix for issue #16196)
In-Reply-To: <d8595c89-332c-a90d-cfe8-9e890612e161@kitware.com>
References: <5785B29E.3060201@scumways.com>
 <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>
 <5786C7EF.6040900@scumways.com>
 <d8595c89-332c-a90d-cfe8-9e890612e161@kitware.com>
Message-ID: <578812B1.7080607@scumways.com>

On 15/07/16 06:47, Brad King wrote:
> On 07/13/2016 06:59 PM, Ben Campbell wrote:
>> I've revised my patch to:
>
> Thanks.  Please use `git format-patch` and then attach it.
> The inline patch was corrupted and does not apply.

Oop - new patch attached!

>> 1/1 Test #268: CMakeOnly.AllFindModules .........***Failed    8.07 sec
>
> It doesn't expect any specific environment.  It is just testing that
> all find modules can complete whether the packages are found or not.
> The "Failed to find" lines are not a problem.  Other output may
> show a real "CMake Error" though.

OK - picking my way through it now - will split into a separate thread.

Thanks,
Ben.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: findgif-version-detection-fix-for-issue-16196.patch
Type: text/x-patch
Size: 3478 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160715/b5af4583/attachment.bin>

From eonikupy at gmail.com  Fri Jul 15 04:43:31 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 17:43:31 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyzKpHVKmtEswda1SqZFrujXFejsD2g0fFDqD_L7cva2AXw@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzJAwo6KJdZjy0vUU5vTM9d_Ei+pc-i4aBkvYYEBv4zdgw@mail.gmail.com>
 <CANQkyzKpHVKmtEswda1SqZFrujXFejsD2g0fFDqD_L7cva2AXw@mail.gmail.com>
Message-ID: <CANQkyzKG3Oi7iPnZ5HyPnfJ8cd62_2ekrxcVq-N85urAZ5dQPw@mail.gmail.com>

A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE <file>] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to <file>. It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE <file>] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file <file>` option that specifies
the report file name instead of foo.output. so [REPORT_FILE <file>] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE <file>]:

3.1. No change for our FindBISON module. `--report-file <file>` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE [<file>]]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE <file>]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE <file>] inserts `--report_file
<file>`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE [<file>]] and [REPORT_FILE <file>]. In this case, <file>
argument of [VERBOSE <file>] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE <file>] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE <file>] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE <file>] between
before and after the patch.

- If we remove <file> from [VERBOSE <file>] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE <file>], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2016-07-15 17:42 GMT+09:00 Eon Jeong <eonikupy at gmail.com>:
> Sorry, resending on list.
>
> 2016-07-15 17:42 GMT+09:00 Eon Jeong <eonikupy at gmail.com>:
>> A year passed so long to reply for a personal reason.
>>
>> Adding to this list because I think it's better to review past
>> discussion on this issue.
>>
>> So let's clearify:
>>
>> 1. Current [VERBOSE <file>] defines `--verbose`, so bison generates
>> foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
>> cmake copies foo.output to <file>. It's intermediate-file-and-copy as
>> said. It's also problematic because using [VERBOSE <file>] forces the
>> report file to be copied to some other name.
>>
>> 2. Since 2007, bison has `--report-file <file>` option that specifies
>> the report file name instead of foo.output. so [REPORT_FILE <file>] is
>> suggested. No intermediate file is made; so using this breaks
>> behavioral backward compatibility. On the other hand, some build
>> systems are still using bison of version before 2007.
>>
>> 3. There are some candidates replacing current [VERBOSE <file>]:
>>
>> 3.1. No change for our FindBISON module. `--report-file <file>` option
>> can be used via COMPILE_FLAGS. Hint this in documentation.
>>
>> 3.2. [VERBOSE [<file>]]. This does not break backward compatibility,
>> and makes someone can choose the report file is copied or not.
>>
>> 3.4. Just [VERBOSE] and [REPORT_FILE <file>]. Independently, [VERBOSE]
>> inserts `--verbose`, [REPORT_FILE <file>] inserts `--report_file
>> <file>`. No more intermediate-file-and-copy, so breaking
>> compatibility, but the clearest solution.
>>
>> 3.5. [VERBOSE [<file>]] and [REPORT_FILE <file>]. In this case, <file>
>> argument of [VERBOSE <file>] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all, but it's
>> dirty when [REPORT_FILE <file>] is cared for lower versions of bison
>> using `cmake -E copy` because [VERBOSE <file>] does the exact thing.
>>
>> And many other solutions possible.
>>
>> 4. Issues are:
>>
>> - Behavioral & syntactic compatibility of [VERBOSE <file>] between
>> before and after the patch.
>>
>> - If we remove <file> from [VERBOSE <file>] so it becomes [VERBOSE],
>> syntactic compatibility breaks.
>>
>> - If we add [REPORT_FILE <file>], it does not work on systems using
>> bison before 2007. We may care it with custom command using `move`, or
>> not.
>>
>> These issues are about how CMake cares about the modules'
>> compatibility and clearness, so I need some direction.
>>
>> I will make appropriate patch for the result.
>>
>> Thanks,
>>
>> Eon
>>
>> 2015-06-25 0:29 GMT+09:00 Brad King <brad.king at kitware.com>:
>>> On 06/24/2015 11:13 AM, ?? wrote:
>>>> The copying command should be run right after each execution of bison.
>>>
>>> Yes.
>>>
>>>> However, add_custom_command never guarantees a running order of
>>>> internal commands. The documentation says, the commands can run
>>>> parallel so never ever put commands with implicit dependencies.
>>>
>>> I'm not sure what text from the documentation you're referencing,
>>> but I think that is warning about listing one output in multiple
>>> independent targets, e.g.
>>>
>>>  add_custom_command(OUTPUT out.txt ...)
>>>  add_custom_target(tgt1 DEPENDS out.txt)
>>>  add_custom_target(tgt2 DEPENDS out.txt)
>>>
>>> That is not the case here.
>>>
>>>> Again, we have two custom commands as a result of passing `VERBOSE` to
>>>> bison_target(). One runs bison, and the other runs cp.
>>>
>>> We only need one add_custom_command call.  It can list both outputs
>>> and have two COMMAND arguments.  Something like (untested):
>>>
>>>       if(...)
>>>         set(_maybe_copy_verbose_output ${BISON_TARGET_ARG_VERBOSE})
>>>         set(_maybe_copy_verbose_command
>>>           COMMAND ${CMAKE_COMMAND} -E copy ${BISON_TARGET_output_path}/${BISON_TARGET_output_name}.output ${BISON_TARGET_ARG_VERBOSE}
>>>           )
>>>       endif()
>>>
>>>       add_custom_command(OUTPUT ${BISON_TARGET_outputs} ${_maybe_copy_verbose_output}
>>>         ${BISON_TARGET_extraoutputs}
>>>         COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput} ${BisonInput}
>>>         ${_maybe_copy_verbose_command}
>>>         DEPENDS ${BisonInput}
>>>         COMMENT "[BISON][${Name}] Building parser with bison ${BISON_VERSION}"
>>>         WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
>>>
>>> When both COMMAND options are present they will run sequentially.
>>>
>>>> If VERBOSE behaved right, REPORT_FILE would not have any benefits over it.
>>>
>>> Wouldn't it be able to skip the intermediate file and copy step?
>>>
>>> -Brad
>>>
>>
>>
>>
>> --
>> Eon Jeong <administrator at korea.ac.kr>
>> Seoul, Rep. of Korea
>> Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.
>
>
>
> --
> Eon Jeong <administrator at korea.ac.kr>
> Seoul, Rep. of Korea
> Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.



-- 
Eon Jeong <administrator at korea.ac.kr>
Seoul, Rep. of Korea
Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.

From eonikupy at gmail.com  Fri Jul 15 04:51:28 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 17:51:28 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <558ACCD4.60701@kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
Message-ID: <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>

A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE <file>] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to <file>. It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE <file>] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file <file>` option that specifies
the report file name instead of foo.output. so [REPORT_FILE <file>] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE <file>]:

3.1. No change for our FindBISON module. `--report-file <file>` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE [<file>]]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE <file>]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE <file>] inserts `--report_file
<file>`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE [<file>]] and [REPORT_FILE <file>]. In this case, <file>
argument of [VERBOSE <file>] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE <file>] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE <file>] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE <file>] between
before and after the patch.

- If we remove <file> from [VERBOSE <file>] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE <file>], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2015-06-25 0:29 GMT+09:00 Brad King <brad.king at kitware.com>:
> On 06/24/2015 11:13 AM, ?? wrote:
>> The copying command should be run right after each execution of bison.
>
> Yes.
>
>> However, add_custom_command never guarantees a running order of
>> internal commands. The documentation says, the commands can run
>> parallel so never ever put commands with implicit dependencies.
>
> I'm not sure what text from the documentation you're referencing,
> but I think that is warning about listing one output in multiple
> independent targets, e.g.
>
>  add_custom_command(OUTPUT out.txt ...)
>  add_custom_target(tgt1 DEPENDS out.txt)
>  add_custom_target(tgt2 DEPENDS out.txt)
>
> That is not the case here.
>
>> Again, we have two custom commands as a result of passing `VERBOSE` to
>> bison_target(). One runs bison, and the other runs cp.
>
> We only need one add_custom_command call.  It can list both outputs
> and have two COMMAND arguments.  Something like (untested):
>
>       if(...)
>         set(_maybe_copy_verbose_output ${BISON_TARGET_ARG_VERBOSE})
>         set(_maybe_copy_verbose_command
>           COMMAND ${CMAKE_COMMAND} -E copy ${BISON_TARGET_output_path}/${BISON_TARGET_output_name}.output ${BISON_TARGET_ARG_VERBOSE}
>           )
>       endif()
>
>       add_custom_command(OUTPUT ${BISON_TARGET_outputs} ${_maybe_copy_verbose_output}
>         ${BISON_TARGET_extraoutputs}
>         COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput} ${BisonInput}
>         ${_maybe_copy_verbose_command}
>         DEPENDS ${BisonInput}
>         COMMENT "[BISON][${Name}] Building parser with bison ${BISON_VERSION}"
>         WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
>
> When both COMMAND options are present they will run sequentially.
>
>> If VERBOSE behaved right, REPORT_FILE would not have any benefits over it.
>
> Wouldn't it be able to skip the intermediate file and copy step?
>
> -Brad
>



-- 
Eon Jeong <administrator at korea.ac.kr>
Seoul, Rep. of Korea
Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.

From eonikupy at gmail.com  Fri Jul 15 05:07:30 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 18:07:30 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyzKG3Oi7iPnZ5HyPnfJ8cd62_2ekrxcVq-N85urAZ5dQPw@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzJAwo6KJdZjy0vUU5vTM9d_Ei+pc-i4aBkvYYEBv4zdgw@mail.gmail.com>
 <CANQkyzKpHVKmtEswda1SqZFrujXFejsD2g0fFDqD_L7cva2AXw@mail.gmail.com>
 <CANQkyzKG3Oi7iPnZ5HyPnfJ8cd62_2ekrxcVq-N85urAZ5dQPw@mail.gmail.com>
Message-ID: <CANQkyzLY=-XRL160Rj4kpiZkYi=cZ9d5nbkmF34O736QatW3Rw@mail.gmail.com>

This mail is not bound to thread because of my mistake. The original
thread is [PATCH] Discussion needed: FindBISON: refine VERBOSE feature
of BISON_TARGET
<http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13487>.
Any review should be made on the thread.

From rakuco at FreeBSD.org  Fri Jul 15 06:46:53 2016
From: rakuco at FreeBSD.org (Raphael Kubo da Costa)
Date: Fri, 15 Jul 2016 12:46:53 +0200
Subject: [cmake-developers] [PATCH] ninja: Generalize check for sysconf(3)
	call.
Message-ID: <20160715104653.3523-1-rakuco@FreeBSD.org>

Commit f9644a2d ("cmGlobalNinjaGenerator: Clarify logic for forcing use
of response files") started considering that negative command line
length values meant forcing the use of response files.

cmNinjaNormalTargetGenerator::calculateCommandLineLength() was not
implemented for certain operating systems such as the BSDs despite the
fact that sysconf(_SC_ARG_MAX) also works there. This caused problems
when generating static libraries, as ar(1) on FreeBSD does not recognize
the @file argument syntax.

By generalizing the checks for whether to use sysconf(_SC_ARG_MAX) this
problem can be worked around and we avoid having to change the #ifdef
for each new operating system implementing sysconf(3) according to
POSIX.
---
 Source/cmNinjaNormalTargetGenerator.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmNinjaNormalTargetGenerator.cxx b/Source/cmNinjaNormalTargetGenerator.cxx
index c34df3c..5e965ff 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -375,7 +375,7 @@ static int calculateCommandLineLengthLimit(int linkRuleLength)
 #ifdef _WIN32
     8000,
 #endif
-#if defined(__APPLE__) || defined(__HAIKU__) || defined(__linux)
+#if defined(_SC_ARG_MAX)
     // for instance ARG_MAX is 2096152 on Ubuntu or 262144 on Mac
     ((int)sysconf(_SC_ARG_MAX)) - 1000,
 #endif
-- 
2.9.0


From brad.king at kitware.com  Fri Jul 15 09:33:09 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 09:33:09 -0400
Subject: [cmake-developers] [PATCH] Improve FindGIF version detection
 (fix for issue #16196)
In-Reply-To: <578812B1.7080607@scumways.com>
References: <5785B29E.3060201@scumways.com>
 <3d2aafc8-7fb0-2424-46a7-e7647613139f@kitware.com>
 <5786C7EF.6040900@scumways.com>
 <d8595c89-332c-a90d-cfe8-9e890612e161@kitware.com>
 <578812B1.7080607@scumways.com>
Message-ID: <5b2eb458-4822-8e62-a431-86f8730d91e1@kitware.com>

On 07/14/2016 06:31 PM, Ben Campbell wrote:
> new patch attached!

Thanks, looks good!  Applied and merged to `next` for testing:

 FindGIF: Detect version from GIF 4.1.6 and above
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a6c227d

Once this is merged to `master` the issue should close automatically.

-Brad


From brad.king at kitware.com  Fri Jul 15 09:33:15 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 09:33:15 -0400
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
Message-ID: <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>

On 07/15/2016 04:51 AM, Eon Jeong wrote:
> review past discussion on this issue.

Thanks for summarizing.

> 3.5. [VERBOSE [<file>]] and [REPORT_FILE <file>]. In this case, <file>
> argument of [VERBOSE <file>] can be either ignored or used (copying
> the report file.) This does not break compatibility at all

I think this is the best solution.  One could also reject use of
both <file> options at the same time.

> - Behavioral & syntactic compatibility of [VERBOSE <file>] between
> before and after the patch.

We need to remain compatible with users of [VERBOSE <file>].

> - If we add [REPORT_FILE <file>], it does not work on systems using
> bison before 2007. We may care it with custom command using `move`, or
> not.

If a project chooses to use REPORT_FILE then it is implying a dependency
on a sufficiently new version of bison, not CMake.  This is fine.

Thanks,
-Brad


From rcdailey.lists at gmail.com  Fri Jul 15 09:47:06 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 15 Jul 2016 08:47:06 -0500
Subject: [cmake-developers] Natvis support in Visual Studio
Message-ID: <CAHd499DGW+H5ubCiDjWO+pDuKRh8O_BO8A_CZCyz=oBEF8bcYw@mail.gmail.com>

Hello CMake devs,

I'm writing code to support Natvis files in Visual Studio 2015
(earlier versions support this as well, I think).

I found an issue regarding this here (is Kitware officially using
github or gitlab? CMake exists on both):
https://gitlab.kitware.com/cmake/cmake/issues/16043

Corresponding link on mantis (deprecated?):
https://cmake.org/Bug/view.php?id=16043

I have some questions. It's not straightforward on  how to implement
this. In cmVisualStudio10TargetGenerator, there is a WriteAllSources()
function which seems to do 2 main things. It seems to look up things
mapped to object files and call WriteSource() on each of those.
Currently it seems to support C, CXX, MASM, and RC language types.
Then there is WriteExtraSources(), which I can only assume is
"everything else". Is this correct?

If I am correct, would I also be correct to assume that
WriteExtraSource should be the one to set the XML element name
(<Natvis>) for *.natvis files based on LANGUAGE being set to NATVIS?
To add to this confusion, cmVisualStudio7Generator::WriteGroup() seems
to do the file extension to LANGUAGE mapping, and I can't tell if the
VS10 generator class is also sharing this code. If it is, do I extend
that function in the VS10 generator class for *.natvis files?
Somewhere I need to be able to automatically set the LANGUAGE property
based on file extension.

Guidance is appreciated!

From brad.king at kitware.com  Fri Jul 15 09:52:54 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 09:52:54 -0400
Subject: [cmake-developers] [PATCH] ninja: Generalize check for
 sysconf(3) call.
In-Reply-To: <20160715104653.3523-1-rakuco@FreeBSD.org>
References: <20160715104653.3523-1-rakuco@FreeBSD.org>
Message-ID: <3a37487a-2cd2-14b5-4df7-1778a10223e1@kitware.com>

On 07/15/2016 06:46 AM, Raphael Kubo da Costa wrote:
> Commit f9644a2d ("cmGlobalNinjaGenerator: Clarify logic for forcing use
> of response files") started considering that negative command line
> length values meant forcing the use of response files.
> 
> cmNinjaNormalTargetGenerator::calculateCommandLineLength() was not
> implemented for certain operating systems

Thanks.  The problem you encountered is actually a regression in 3.6.0.
I've fixed it here:

 Ninja: Do not force response files when no sysconf(3) limit is used
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86dd2427

and queued the change for merge to `release` for 3.6.1.

I've also applied your change on `master` for development toward 3.7:

 Ninja: Generalize check for sysconf(3) call
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ec17e61

Thanks,
-Brad


From brad.king at kitware.com  Fri Jul 15 10:05:27 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 10:05:27 -0400
Subject: [cmake-developers] Natvis support in Visual Studio
In-Reply-To: <CAHd499DGW+H5ubCiDjWO+pDuKRh8O_BO8A_CZCyz=oBEF8bcYw@mail.gmail.com>
References: <CAHd499DGW+H5ubCiDjWO+pDuKRh8O_BO8A_CZCyz=oBEF8bcYw@mail.gmail.com>
Message-ID: <d214b2d2-db18-f049-b6c1-cac4ba0c7a48@kitware.com>

On 07/15/2016 09:47 AM, Robert Dailey wrote:
> is Kitware officially using github or gitlab? CMake exists on both

The GitLab repo is used as the issue tracker (recently migrated from Mantis).
The GitHub repo is offered as a convenience for the community but is not
the official path for contribution.  See CONTRIBUTING.rst for the documented
official contribution path.  GitLab MRs are also allowed but not documented
yet because we're still experimenting with them.

> mapped to object files and call WriteSource() on each of those.
> Currently it seems to support C, CXX, MASM, and RC language types.
> Then there is WriteExtraSources(), which I can only assume is
> "everything else". Is this correct?

Yes.  WriteSource() is for first-class language that use enable_language().
Those languages need to be supported by all generators so adding natvis to
it may not make sense.

> If I am correct, would I also be correct to assume that
> WriteExtraSource should be the one to set the XML element name
> (<Natvis>) for *.natvis files based on LANGUAGE being set to NATVIS?

Yes.  It already has a table of VS-specific special cases checked by
file extension.  See also:

 VS: Add a VS_TOOL_OVERRIDE source file property
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

> To add to this confusion, cmVisualStudio7Generator::WriteGroup()

That is only for VS <= 9.

> Somewhere I need to be able to automatically set the LANGUAGE property
> based on file extension.

The LANGUAGE property is meant to be set by projects.  If it is not
set then we detect the language.  We don't need to explicitly set
the property based on the extension.  I think WriteExtraSource is
the only place that needs modification for this.

-Brad


From rcdailey.lists at gmail.com  Fri Jul 15 10:23:45 2016
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 15 Jul 2016 09:23:45 -0500
Subject: [cmake-developers] Natvis support in Visual Studio
In-Reply-To: <d214b2d2-db18-f049-b6c1-cac4ba0c7a48@kitware.com>
References: <CAHd499DGW+H5ubCiDjWO+pDuKRh8O_BO8A_CZCyz=oBEF8bcYw@mail.gmail.com>
 <d214b2d2-db18-f049-b6c1-cac4ba0c7a48@kitware.com>
Message-ID: <CAHd499D+yD7Gk3tnbjPFMSZ_ScrSbz9M+jEj2um+17i+3aZ1hg@mail.gmail.com>

On Fri, Jul 15, 2016 at 9:05 AM, Brad King <brad.king at kitware.com> wrote:
>  VS: Add a VS_TOOL_OVERRIDE source file property
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

Nice, I wasn't aware that there was already a feature in place to
support this. Given that this exists, is there any point to adding an
explicit code change to support natvis files?

I will install a 3.6.2 nightly build and try out that property. I like
that idea, the only downside is you lose the automatic mapping based
on file extension. I have a simple patch attached that shows the
change I've made to the code. I don't have time ATM to write a unit
test for it, but hopefully you can build onto this if you find it
valuable? Seems the change is simple based on your explanation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-NATVIS-files-in-VS10-generator.patch
Type: application/octet-stream
Size: 885 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160715/13924be4/attachment-0001.obj>

From eonikupy at gmail.com  Fri Jul 15 10:35:03 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 23:35:03 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
Message-ID: <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>

Thank you clarifying the basic rules.

2016-07-15 22:33 GMT+09:00 Brad King <brad.king at kitware.com>:
>> 3.5. [VERBOSE [<file>]] and [REPORT_FILE <file>]. In this case, <file>
>> argument of [VERBOSE <file>] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all
>
> I think this is the best solution.  One could also reject use of
> both <file> options at the same time.

[VERBOSE [<file>]] was my hope, but it's not easy. Since FindBISON now
uses CMakeParseArguments, a keyword can't be used both as an option
and as a one-value keyword.

Possible solutions are:

- Splitting [VERBOSE <file>] into [VERBOSE] (just `--verbose`) and
[VERBOSE_FILE <file>] (`--verbose` and copy). It breaks the
compatibility slightly, but I think this is an approvable break even
without REPORT_FILE because there was no choice to get just
default-named output file. In this case, "VERBOSE", "VERBOSE
REPORT_FILE <file>" or "VERBOSE_FILE <file>" or any combinations can
be used.

- Let [VERBOSE <file>] and [REPORT_FILE <file>] independently exist.
[VERBOSE <file>] means `--verbose` and copying to <file>, and
[REPORT_FILE <file>] means `--report-file <file>` *and `--verbose`*.
cf. In bison, `--report-file <file>` does not imply `--verbose`.

- Extending CMakeParseArguments so a one-value keyword can be also
used as options when it's passed both in <options> and
<one_value_keywords>. Then combinations "VERBOSE", "VERBOSE <file>",
"VERBOSE REPORT_FILE <file>", "VERBOSE <file> REPORT_FILE <file>" can
be used.

- Not using CMakeParseArguments.

Sorry for making mistake. I was thinking wrong about how
CMakeParseArguments works.

Thanks,

Eon

From brad.king at kitware.com  Fri Jul 15 10:38:45 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 10:38:45 -0400
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
Message-ID: <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>

On 07/15/2016 10:35 AM, Eon Jeong wrote:
> [VERBOSE [<file>]] was my hope, but it's not easy. Since FindBISON now
> uses CMakeParseArguments, a keyword can't be used both as an option
> and as a one-value keyword.

Just make it a multi-value keyword and then reject multiple values
manually after cmake_parse_arguments returns.

-Brad


From brad.king at kitware.com  Fri Jul 15 10:41:19 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 10:41:19 -0400
Subject: [cmake-developers] Natvis support in Visual Studio
In-Reply-To: <CAHd499D+yD7Gk3tnbjPFMSZ_ScrSbz9M+jEj2um+17i+3aZ1hg@mail.gmail.com>
References: <CAHd499DGW+H5ubCiDjWO+pDuKRh8O_BO8A_CZCyz=oBEF8bcYw@mail.gmail.com>
 <d214b2d2-db18-f049-b6c1-cac4ba0c7a48@kitware.com>
 <CAHd499D+yD7Gk3tnbjPFMSZ_ScrSbz9M+jEj2um+17i+3aZ1hg@mail.gmail.com>
Message-ID: <af3831e7-3ccb-1d74-bd3d-5c34f0f93dfe@kitware.com>

On 07/15/2016 10:23 AM, Robert Dailey wrote:
> Nice, I wasn't aware that there was already a feature in place to
> support this. Given that this exists, is there any point to adding an
> explicit code change to support natvis files?

The VS_TOOL_OVERRIDE option is nice to allow projects a path forward
for types that CMake doesn't yet support.  However, we should still
add types as needed to CMake.

> I have a simple patch attached that shows the change I've made to the code.

Applied, thanks:

 VS: Add support for NATVIS files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6290cff

-Brad


From eonikupy at gmail.com  Fri Jul 15 10:45:11 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 23:45:11 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
Message-ID: <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>

2016-07-15 23:38 GMT+09:00 Brad King <brad.king at kitware.com>:
> Just make it a multi-value keyword and then reject multiple values
> manually after cmake_parse_arguments returns.

I considered that way, but doing this can't figure "VERBOSE" used
without <file> from never used. same empty string value.

Eon

From brad.king at kitware.com  Fri Jul 15 10:52:23 2016
From: brad.king at kitware.com (Brad King)
Date: Fri, 15 Jul 2016 10:52:23 -0400
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
 <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
Message-ID: <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>

On 07/15/2016 10:45 AM, Eon Jeong wrote:
> I considered that way, but doing this can't figure "VERBOSE" used
> without <file> from never used. same empty string value.

You could hack it with something like

  if("${ARGN}" MATCHES ";VERBOSE;")

if the value comes back empty.

-Brad


From eonikupy at gmail.com  Fri Jul 15 10:54:32 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Fri, 15 Jul 2016 23:54:32 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
 <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
 <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
Message-ID: <CANQkyzLsB6hBi6Xf4mJzmWWsSu5MegALm-PJLvkXTvXTEsotPA@mail.gmail.com>

Thanks Brad, I'll try with that hack.

Eon

From ben.boeckel at kitware.com  Fri Jul 15 11:44:25 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 15 Jul 2016 11:44:25 -0400
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
 <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
 <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
Message-ID: <20160715154425.GA18154@megas.kitware.com>

On Fri, Jul 15, 2016 at 10:52:23 -0400, Brad King wrote:
> On 07/15/2016 10:45 AM, Eon Jeong wrote:
> > I considered that way, but doing this can't figure "VERBOSE" used
> > without <file> from never used. same empty string value.
> 
> You could hack it with something like
> 
>   if("${ARGN}" MATCHES ";VERBOSE;")
> 
> if the value comes back empty.

Avoiding regexes here would be better:

    list(FIND ARGN "VERBOSE" has_verbose)

--Ben

From eonikupy at gmail.com  Fri Jul 15 14:14:38 2016
From: eonikupy at gmail.com (Eon Jeong)
Date: Sat, 16 Jul 2016 03:14:38 +0900
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <20160715154425.GA18154@megas.kitware.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
 <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
 <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
 <20160715154425.GA18154@megas.kitware.com>
Message-ID: <CANQkyzJA4i6WxoD-GPk=aC-fy5Z0r4s11QJmK7_PhuP+VEcDpw@mail.gmail.com>

I wrote new patches for each of: changing usage of VERBOSE, new option
REPORT_FILE, and refactoring all of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindBISON-Change-usage-of-VERBOSE-file-to-VERBOSE-fi.patch
Type: application/octet-stream
Size: 6139 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160716/dff97f84/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-FindBISON-Add-REPORT_FILE-option-to-pass-report-file.patch
Type: application/octet-stream
Size: 3466 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160716/dff97f84/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-FindBISON-Refactor-public-and-inner-macro-routines.patch
Type: application/octet-stream
Size: 5751 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160716/dff97f84/attachment-0002.obj>

From davispuh at gmail.com  Sat Jul 16 20:22:09 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Sun, 17 Jul 2016 03:22:09 +0300
Subject: [cmake-developers] [PATCH v5 1/2] Refactor FStream (basic_ifstream
	and basic_ofstream classes)
Message-ID: <20160717002210.31226-1-davispuh@gmail.com>

Use common basic_efilebuf for both to reduce code duplication.
---
 Source/kwsys/FStream.hxx.in | 164 +++++++++++++++++++++++++-------------------
 1 file changed, 95 insertions(+), 69 deletions(-)

diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in
index 681e4d8..248b0cb 100644
--- a/Source/kwsys/FStream.hxx.in
+++ b/Source/kwsys/FStream.hxx.in
@@ -30,136 +30,162 @@ namespace @KWSYS_NAMESPACE@
       typedef std::basic_filebuf<CharType,Traits> my_base_type;
       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
       {
+        const std::wstring wstr = Encoding::ToWide(s);
         return static_cast<basic_filebuf*>(
-          my_base_type::open(Encoding::ToWide(s).c_str(), mode)
+          my_base_type::open(wstr.c_str(), mode)
           );
       }
   };
 
   template<typename CharType,typename Traits = std::char_traits<CharType> >
-  class basic_ifstream : public std::basic_istream<CharType,Traits>
+  class basic_efilebuf
   {
+    public:
+      typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+
+      basic_efilebuf()
+      {
+        buf_ = 0;
+      }
+
+      bool _open(char const *file_name,std::ios_base::openmode mode)
+      {
+        if (is_open()) {
+          return false;
+        }
+        const bool success = buf_->open(file_name,mode) != 0;
+        return success;
+      }
+
+      bool is_open()
+      {
+        if (!buf_) {
+          return false;
+        }
+        return buf_->is_open();
+      }
+
+      bool is_open() const
+      {
+        if (!buf_) {
+          return false;
+        }
+        return buf_->is_open();
+      }
+
+      bool _close()
+      {
+        bool success = false;
+        if (buf_) {
+          success = buf_->close() != 0;
+        }
+        return success;
+      }
+
+      static void _set_state(bool success, std::basic_ios<CharType,Traits> *ios)
+      {
+        if (!success) {
+          ios->setstate(std::ios_base::failbit);
+        } else {
+          ios->clear();
+        }
+      }
+
+      ~basic_efilebuf()
+     {
+       if (buf_) {
+         delete buf_;
+       }
+     }
+
+    protected:
+      internal_buffer_type* buf_;
+  };
+
+template<typename CharType,typename Traits = std::char_traits<CharType> >
+class basic_ifstream : public std::basic_istream<CharType,Traits>,
+                       public basic_efilebuf<CharType,Traits>
+{
+  using basic_efilebuf<CharType,Traits>::is_open;
+
   public:
-    typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+    typedef typename basic_efilebuf<CharType, Traits>::internal_buffer_type internal_buffer_type;
     typedef std::basic_istream<CharType,Traits> internal_stream_type;
 
     basic_ifstream() : internal_stream_type(new internal_buffer_type())
     {
-      buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+      this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
     }
     explicit basic_ifstream(char const *file_name,
                             std::ios_base::openmode mode = std::ios_base::in)
       : internal_stream_type(new internal_buffer_type())
     {
-      buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+      this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
       open(file_name,mode);
     }
+
     void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
     {
-      if(!buf_->open(file_name,mode | std::ios_base::in))
-        {
-        this->setstate(std::ios_base::failbit);
-        }
-      else
-        {
-        this->clear();
-        }
-    }
-    bool is_open()
-    {
-      return buf_->is_open();
-    }
-    bool is_open() const
-    {
-      return buf_->is_open();
+      mode = mode | std::ios_base::in;
+      this->_set_state(this->_open(file_name, mode), this);
     }
+
     void close()
     {
-      if(!buf_->close())
-        {
-        this->setstate(std::ios_base::failbit);
-        }
-      else
-      {
-        this->clear();
-      }
+      this->_set_state(this->_close(), this);
     }
 
     internal_buffer_type *rdbuf() const
     {
-      return buf_;
+      return this->buf_;
     }
 
     ~basic_ifstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
     {
-      buf_->close();
-      delete buf_;
+      close();
     }
-
-  private:
-    internal_buffer_type* buf_;
 };
 
 template<typename CharType,typename Traits = std::char_traits<CharType> >
-class basic_ofstream : public std::basic_ostream<CharType,Traits>
+class basic_ofstream : public std::basic_ostream<CharType,Traits>,
+                       public basic_efilebuf<CharType,Traits>
 {
+  using basic_efilebuf<CharType,Traits>::is_open;
+
   public:
-  typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+  typedef typename basic_efilebuf<CharType, Traits>::internal_buffer_type internal_buffer_type;
   typedef std::basic_ostream<CharType,Traits> internal_stream_type;
 
   basic_ofstream() : internal_stream_type(new internal_buffer_type())
   {
-  buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+    this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
   }
   explicit basic_ofstream(char const *file_name,std::ios_base::openmode mode = std::ios_base::out) :
   internal_stream_type(new internal_buffer_type())
   {
-    buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
+    this->buf_ = static_cast<internal_buffer_type *>(internal_stream_type::rdbuf());
     open(file_name,mode);
   }
   void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::out)
   {
-    if(!buf_->open(file_name,mode | std::ios_base::out))
-    {
-    this->setstate(std::ios_base::failbit);
-    }
-    else
-    {
-    this->clear();
-    }
-  }
-  bool is_open()
-  {
-    return buf_->is_open();
-  }
-  bool is_open() const
-  {
-    return buf_->is_open();
+    mode = mode | std::ios_base::out;
+    this->_set_state(this->_open(file_name, mode), this);
   }
+
   void close()
   {
-    if(!buf_->close())
-      {
-      this->setstate(std::ios_base::failbit);
-      }
-    else
-      {
-      this->clear();
-      }
+    this->_set_state(this->_close(), this);
   }
 
   internal_buffer_type *rdbuf() const
   {
-    return buf_.get();
+    return this->buf_;
   }
+
   ~basic_ofstream() @KWSYS_NAMESPACE at _FStream_NOEXCEPT
   {
-    buf_->close();
-    delete buf_;
+    close();
   }
-
-  private:
-  internal_buffer_type* buf_;
 };
 
   typedef basic_ifstream<char> ifstream;
-- 
2.9.0


From davispuh at gmail.com  Sat Jul 16 20:22:10 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Sun, 17 Jul 2016 03:22:10 +0300
Subject: [cmake-developers] [PATCH v5 2/2] Add MinGW support for FStream
In-Reply-To: <20160717002210.31226-1-davispuh@gmail.com>
References: <20160717002210.31226-1-davispuh@gmail.com>
Message-ID: <20160717002210.31226-2-davispuh@gmail.com>

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard
and it's only present for MSVC but it isn't present in libstdc++ (MinGW)
so we implement this functionality using GNU libstdc++ stdio_filebuf
extension and _wfopen function.
---
 Source/kwsys/CMakeLists.txt            |  5 ++
 Source/kwsys/Configure.hxx.in          |  7 ++-
 Source/kwsys/FStream.hxx.in            | 86 ++++++++++++++++++++++++++++++----
 Source/kwsys/kwsysPlatformTestsCXX.cxx |  6 +++
 bootstrap                              | 11 +++++
 5 files changed, 105 insertions(+), 10 deletions(-)

diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 33a97e6..297a7bd 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -636,6 +636,11 @@ IF(KWSYS_USE_SystemInformation)
   ENDIF()
 ENDIF()
 
+IF(KWSYS_USE_FStream)
+  KWSYS_PLATFORM_CXX_TEST(KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H
+    "Checking whether <ext/stdio_filebuf.h> is available" DIRECT)
+ENDIF()
+
 #-----------------------------------------------------------------------------
 # Choose a directory for the generated headers.
 IF(NOT KWSYS_HEADER_ROOT)
diff --git a/Source/kwsys/Configure.hxx.in b/Source/kwsys/Configure.hxx.in
index ff8e49d..4ce680d 100644
--- a/Source/kwsys/Configure.hxx.in
+++ b/Source/kwsys/Configure.hxx.in
@@ -17,6 +17,8 @@
 
 /* Whether wstring is available.  */
 #define @KWSYS_NAMESPACE at _STL_HAS_WSTRING @KWSYS_STL_HAS_WSTRING@
+/* Whether <ext/stdio_filebuf.h> is available. */
+#define @KWSYS_NAMESPACE at _CXX_HAS_EXT_STDIO_FILEBUF_H @KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H@
 
 /* If building a C++ file in kwsys itself, give the source file
    access to the macros without a configured namespace.  */
@@ -24,8 +26,9 @@
 # if !@KWSYS_NAMESPACE at _NAME_IS_KWSYS
 #  define kwsys     @KWSYS_NAMESPACE@
 # endif
-# define KWSYS_NAME_IS_KWSYS            @KWSYS_NAMESPACE at _NAME_IS_KWSYS
-# define KWSYS_STL_HAS_WSTRING          @KWSYS_NAMESPACE at _STL_HAS_WSTRING
+# define KWSYS_NAME_IS_KWSYS               @KWSYS_NAMESPACE at _NAME_IS_KWSYS
+# define KWSYS_STL_HAS_WSTRING             @KWSYS_NAMESPACE at _STL_HAS_WSTRING
+# define KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H @KWSYS_NAMESPACE at _CXX_HAS_EXT_STDIO_FILEBUF_H
 #endif
 
 #endif
diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in
index 248b0cb..c13f91d 100644
--- a/Source/kwsys/FStream.hxx.in
+++ b/Source/kwsys/FStream.hxx.in
@@ -12,20 +12,32 @@
 #ifndef @KWSYS_NAMESPACE at _FStream_hxx
 #define @KWSYS_NAMESPACE at _FStream_hxx
 
+#include <@KWSYS_NAMESPACE@/Configure.hxx>
 #include <@KWSYS_NAMESPACE@/Encoding.hxx>
 #include <fstream>
+#if defined(_WIN32)
+#  if !defined(_MSC_VER) && @KWSYS_NAMESPACE at _CXX_HAS_EXT_STDIO_FILEBUF_H
+#    include <ext/stdio_filebuf.h>
+#  elif !defined(_MSC_VER) || _MSC_VER < 1400
+#    pragma message("WARNING: Opening non-ASCII files might fail!")
+#  endif
+#endif
 
 namespace @KWSYS_NAMESPACE@
 {
-#if defined(_MSC_VER) && _MSC_VER >= 1400
+#if defined(_WIN32) && (defined(_MSC_VER) || @KWSYS_NAMESPACE at _CXX_HAS_EXT_STDIO_FILEBUF_H)
 # if defined(_NOEXCEPT)
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT _NOEXCEPT
 # else
 #  define @KWSYS_NAMESPACE at _FStream_NOEXCEPT
 # endif
+
+#if defined(_MSC_VER)
+
   template<typename CharType,typename Traits>
   class basic_filebuf : public std::basic_filebuf<CharType,Traits>
   {
+# if _MSC_VER >= 1400
     public:
       typedef std::basic_filebuf<CharType,Traits> my_base_type;
       basic_filebuf *open(char const *s,std::ios_base::openmode mode)
@@ -35,25 +47,73 @@ namespace @KWSYS_NAMESPACE@
           my_base_type::open(wstr.c_str(), mode)
           );
       }
+# endif
+  };
+
+#else
+
+  inline std::wstring getcmode(const std::ios_base::openmode mode) {
+    std::wstring cmode;
+    bool plus = false;
+    if (mode & std::ios_base::app) {
+      cmode += L"a";
+      plus = mode & std::ios_base::in ? true : false;
+    } else if (mode & std::ios_base::trunc ||
+                (mode & std::ios_base::out && (mode & std::ios_base::in) == 0)) {
+      cmode += L"w";
+      plus = mode & std::ios_base::in ? true : false;
+    } else {
+      cmode += L"r";
+      plus = mode & std::ios_base::out ? true : false;
+    }
+    if (plus) {
+      cmode += L"+";
+    }
+    if (mode & std::ios_base::binary) {
+      cmode += L"b";
+    } else {
+      cmode += L"t";
+    }
+    return cmode;
   };
 
+#endif
+
   template<typename CharType,typename Traits = std::char_traits<CharType> >
   class basic_efilebuf
   {
     public:
+#if defined(_MSC_VER)
       typedef basic_filebuf<CharType,Traits> internal_buffer_type;
+#else
+      typedef __gnu_cxx::stdio_filebuf<CharType,Traits> internal_buffer_type;
+#endif
 
-      basic_efilebuf()
+      basic_efilebuf() : file_(0)
       {
         buf_ = 0;
       }
 
       bool _open(char const *file_name,std::ios_base::openmode mode)
       {
-        if (is_open()) {
+        if (is_open() || file_) {
           return false;
         }
+#if defined(_MSC_VER)
         const bool success = buf_->open(file_name,mode) != 0;
+#else
+        const std::wstring wstr = Encoding::ToWide(file_name);
+        bool success = false;
+        std::wstring cmode = getcmode(mode);
+        file_ = _wfopen(wstr.c_str(), cmode.c_str());
+        if (file_) {
+          if (buf_) {
+            delete buf_;
+          }
+          buf_ = new internal_buffer_type(file_, mode);
+          success = true;
+        }
+#endif
         return success;
       }
 
@@ -78,12 +138,21 @@ namespace @KWSYS_NAMESPACE@
         bool success = false;
         if (buf_) {
           success = buf_->close() != 0;
+#if !defined(_MSC_VER)
+          if (file_) {
+            success = fclose(file_) == 0 ? success : false;
+            file_ = 0;
+          }
+#endif
         }
         return success;
       }
 
-      static void _set_state(bool success, std::basic_ios<CharType,Traits> *ios)
+      static void _set_state(bool success, std::basic_ios<CharType,Traits> *ios, basic_efilebuf* efilebuf)
       {
+#if !defined(_MSC_VER)
+        ios->rdbuf(efilebuf->buf_);
+#endif
         if (!success) {
           ios->setstate(std::ios_base::failbit);
         } else {
@@ -100,6 +169,7 @@ namespace @KWSYS_NAMESPACE@
 
     protected:
       internal_buffer_type* buf_;
+      FILE *file_;
   };
 
 template<typename CharType,typename Traits = std::char_traits<CharType> >
@@ -127,12 +197,12 @@ class basic_ifstream : public std::basic_istream<CharType,Traits>,
     void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::in)
     {
       mode = mode | std::ios_base::in;
-      this->_set_state(this->_open(file_name, mode), this);
+      this->_set_state(this->_open(file_name, mode), this, this);
     }
 
     void close()
     {
-      this->_set_state(this->_close(), this);
+      this->_set_state(this->_close(), this, this);
     }
 
     internal_buffer_type *rdbuf() const
@@ -169,12 +239,12 @@ class basic_ofstream : public std::basic_ostream<CharType,Traits>,
   void open(char const *file_name,std::ios_base::openmode mode = std::ios_base::out)
   {
     mode = mode | std::ios_base::out;
-    this->_set_state(this->_open(file_name, mode), this);
+    this->_set_state(this->_open(file_name, mode), this, this);
   }
 
   void close()
   {
-    this->_set_state(this->_close(), this);
+    this->_set_state(this->_close(), this, this);
   }
 
   internal_buffer_type *rdbuf() const
diff --git a/Source/kwsys/kwsysPlatformTestsCXX.cxx b/Source/kwsys/kwsysPlatformTestsCXX.cxx
index fc87f91..8414692 100644
--- a/Source/kwsys/kwsysPlatformTestsCXX.cxx
+++ b/Source/kwsys/kwsysPlatformTestsCXX.cxx
@@ -349,3 +349,9 @@ int main()
 void f(std ::wstring*) {}
 int main() { return 0; }
 #endif
+
+#ifdef TEST_KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H
+#include <ext/stdio_filebuf.h>
+int main() { return 0; }
+#endif
+
diff --git a/bootstrap b/bootstrap
index 0411c64..c0628e1 100755
--- a/bootstrap
+++ b/bootstrap
@@ -512,6 +512,7 @@ cmake_kwsys_config_replace_string ()
                 s/@KWSYS_LFS_REQUESTED@/${KWSYS_LFS_REQUESTED}/g;
                 s/@KWSYS_NAME_IS_KWSYS@/${KWSYS_NAME_IS_KWSYS}/g;
                 s/@KWSYS_STL_HAS_WSTRING@/${KWSYS_STL_HAS_WSTRING}/g;
+                s/@KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H@/${KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H}/g;
                }" >> "${OUTFILE}${_tmp}"
     if [ -f "${OUTFILE}${_tmp}" ]; then
       if "${_diff}" "${OUTFILE}" "${OUTFILE}${_tmp}" > /dev/null 2> /dev/null ; then
@@ -1183,6 +1184,7 @@ KWSYS_BUILD_SHARED=0
 KWSYS_LFS_AVAILABLE=0
 KWSYS_LFS_REQUESTED=0
 KWSYS_STL_HAS_WSTRING=0
+KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H=0
 KWSYS_CXX_HAS_SETENV=0
 KWSYS_CXX_HAS_UNSETENV=0
 KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H=0
@@ -1225,6 +1227,15 @@ else
   echo "${cmake_cxx_compiler} does not have stl wstring"
 fi
 
+if cmake_try_run "${cmake_cxx_compiler}" \
+  "${cmake_cxx_flags} -DTEST_KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H" \
+  "${cmake_source_dir}/Source/kwsys/kwsysPlatformTestsCXX.cxx" >> cmake_bootstrap.log 2>&1; then
+  KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H=1
+  echo "${cmake_cxx_compiler} has <ext/stdio_filebuf.h>"
+else
+  echo "${cmake_cxx_compiler} does not have <ext/stdio_filebuf.h>"
+fi
+
 # Just to be safe, let us store compiler and flags to the header file
 
 cmake_bootstrap_version='$Revision$'
-- 
2.9.0


From garlicbready at googlemail.com  Sun Jul 17 19:59:18 2016
From: garlicbready at googlemail.com (RW)
Date: Mon, 18 Jul 2016 00:59:18 +0100
Subject: [cmake-developers] Question over language bindings / daemon
Message-ID: <CAMMCZ5P69My6xpbbf1NS0PFLi6Ys2CnYqZ_CyH5TS7-hxG8KjQ@mail.gmail.com>

Hi,
I've got a couple of questions surrounding the use of other languages with
cmake
I've read up on some of the past threads associated with this one, so I
know there's been a lot of discussion on this already.

Just to give a bit of history there's a couple of situations where I wanted
to use cmake for cross platform applications
The main one is for use with arm embedded C++ code using the mbed library
This is similar to gcc4mbed, but using cmake to handle the generation of
the build scripts
The other use was for .Net projects, although the use of .Net Core has
largely eliminated that one now as far as cross platform builds is concerned

To begin with I tried using the cmake language directly, but I found it
difficult to debug and more verbose when declaring functions etc
also I needed to use a toolchainfile which required running cmake multiple
times

I'm a big fan of python (vs lua) for the following reasons
1. I can single step debug it within VStudio
2. It has a large set of libs available
3. Within the ide I'm using it has auto completion

I decided one idea might be just a wrapper to generate CMakeFiles using a
python library
however while this partially works (code is incomplete) I got tired of
wrapping each and every function very quickly
https://github.com/grbd/GBD.Build.BlackJack

Question 1
Will the new daemon mode if it's included have all the commands associated
with a CMakeFile?
(In other-words could I write a python library that could just pipe
commands into it, instead of generating a separate CMakeFile)

Question 2
I had a look at the way the functions are written within the code
while I could extract a list of them using something like CppSharp (for
example to extract a list of everything that inherits from cmCommand)
There doesn't seem to be any metadata that describes arguments that are
passed into a given function. (only that each function takes a vector of
strings).
Do you know if there's any xml or associated metadata (perhaps used to
generate the docs) for which arguments are associated with a given function?

Many Thanks,
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160718/b528bd8c/attachment.html>

From Tobias.Hunger at qt.io  Mon Jul 18 08:32:27 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Mon, 18 Jul 2016 12:32:27 +0000
Subject: [cmake-developers] Question over language bindings / daemon
In-Reply-To: <CAMMCZ5P69My6xpbbf1NS0PFLi6Ys2CnYqZ_CyH5TS7-hxG8KjQ@mail.gmail.com>
References: <CAMMCZ5P69My6xpbbf1NS0PFLi6Ys2CnYqZ_CyH5TS7-hxG8KjQ@mail.gmail.com>
Message-ID: <1468845145.765.21.camel@qt.io>

Hi Rick,

On Mo, 2016-07-18 at 00:59 +0100, RW via cmake-developers wrote:
> Question 1
> Will the new daemon mode if it's included have all the commands associated
> with a CMakeFile?
> (In other-words could I write a python library that could just pipe
> commands into it, instead of generating a separate CMakeFile)

It's server mode now:-)

No, daemon mode will provide commands to query the build graph etc., but it will
not be usable to feed CMakeLists.txt-commands to cmake one by one.

> Question 2
> I had a look at the way the functions are written within the code
> while I could extract a list of them using something like CppSharp (for
> example to extract a list of everything that inherits from cmCommand)
> There doesn't seem to be any metadata that describes arguments that are
> passed into a given function. (only that each function takes a vector of
> strings).
> Do you know if there's any xml or associated metadata (perhaps used to
> generate the docs) for which arguments are associated with a given function?

This in turn is in scope for server mode (not at the start, but later): That
information is a by-product of the idea of server mode helping IDEs with code-
completion of CMakeLists.txt files.

Best Regards,
Tobias

-- 
Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From brad.king at kitware.com  Mon Jul 18 09:14:42 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 18 Jul 2016 09:14:42 -0400
Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine
 VERBOSE feature of BISON_TARGET
In-Reply-To: <CANQkyzJA4i6WxoD-GPk=aC-fy5Z0r4s11QJmK7_PhuP+VEcDpw@mail.gmail.com>
References: <CANQkyzL9Y8M04193ZENBnraoF1h1r8FywBpviqsaZF_qe9X9HA@mail.gmail.com>
 <55880FFB.20303@kitware.com>
 <CANQkyzJULMJ32wJnZoex6WRmwwAh-64cVkoV6db6ybCUe8V42A@mail.gmail.com>
 <558ACCD4.60701@kitware.com>
 <CANQkyzLoCSDgT6J1hjzMZs8+KzBsPh5U8SJk4c8VMSuOFDEBeQ@mail.gmail.com>
 <e04499a0-8a04-cff6-adf6-af0aaf5cc2bb@kitware.com>
 <CANQkyz+C03AhpnaSWmkfZbJt5JVckZZxBrgKvNW40oVQtgYMHA@mail.gmail.com>
 <c37a7eb6-a818-2ddc-1ef7-aa9952a8db7e@kitware.com>
 <CANQkyzKEQdwSFHAWDUr+sybe7SxdM2dXT8iN9nrJtrH27PPtgQ@mail.gmail.com>
 <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com>
 <20160715154425.GA18154@megas.kitware.com>
 <CANQkyzJA4i6WxoD-GPk=aC-fy5Z0r4s11QJmK7_PhuP+VEcDpw@mail.gmail.com>
Message-ID: <4addf8b8-e244-a251-e4f1-44ef20d0097f@kitware.com>

On 07/15/2016 02:14 PM, Eon Jeong wrote:
> I wrote new patches for each of: changing usage of VERBOSE, new option
> REPORT_FILE, and refactoring all of them.

Thanks, applied:

 FindBISON: Change usage of [VERBOSE <file>] to [VERBOSE [<file>]]
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2497aa

 FindBISON: Add REPORT_FILE option to pass --report-file=FILE
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c42e63a9

 FindBISON: Refactor public and inner macro routines
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab8d5d0f

-Brad


From brad.king at kitware.com  Mon Jul 18 09:28:12 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 18 Jul 2016 09:28:12 -0400
Subject: [cmake-developers] [PATCH v5 2/2] Add MinGW support for FStream
In-Reply-To: <20160717002210.31226-2-davispuh@gmail.com>
References: <20160717002210.31226-1-davispuh@gmail.com>
 <20160717002210.31226-2-davispuh@gmail.com>
Message-ID: <9542e620-e746-117b-bcaf-a3d49f182ea8@kitware.com>

On 07/16/2016 08:22 PM, D?vis Mos?ns wrote:
> std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard
> and it's only present for MSVC but it isn't present in libstdc++ (MinGW)
> so we implement this functionality using GNU libstdc++ stdio_filebuf
> extension and _wfopen function.

Thanks.  I've added this and its parent commit to KWSys:

 http://review.source.kitware.com/21339

-Brad


From brad.king at kitware.com  Mon Jul 18 09:53:04 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 18 Jul 2016 09:53:04 -0400
Subject: [cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct
 encoding for SystemTools::GetEnv
In-Reply-To: <CAOE4rSyWp3mgW=jPW=W72vNSn638oCeRWGzEvMi=6vEqL4kUNQ@mail.gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707223217.11825-1-davispuh@gmail.com> <577FA4CA.2050209@kitware.com>
 <CAOE4rSyWp3mgW=jPW=W72vNSn638oCeRWGzEvMi=6vEqL4kUNQ@mail.gmail.com>
Message-ID: <8acba8e3-049c-0f9c-ccc5-0d8260d0a3c3@kitware.com>

On 07/08/2016 09:26 AM, D?vis Mos?ns wrote:
>> Once integrated there I can update it in CMake and then move
>> on to more of your patches.
> 
> Great! Thanks!

This is now in KWSys `master`.  I've updated CMake's KWSys:

 Merge branch 'upstream-KWSys' into update-kwsys
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03407040

I'll reply to your other patch messages as appropriate.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jul 18 10:00:11 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 18 Jul 2016 10:00:11 -0400
Subject: [cmake-developers] [PATCH v4 3/4] Use SystemTools::GetEnv and
 HasEnv functions
In-Reply-To: <20160707215406.16180-3-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-3-davispuh@gmail.com>
Message-ID: <3ff37385-b716-d197-a5b9-0dc1d5595085@kitware.com>

On 07/07/2016 05:54 PM, D?vis Mos?ns wrote:
>  Source/CPack/cmCPackGenerator.cxx           |  8 +++---
>  Source/CTest/cmCTestCoverageHandler.cxx     | 12 ++++-----
>  Source/CTest/cmCTestCurl.cxx                | 27 ++++++++++----------
>  Source/CTest/cmCTestMultiProcessHandler.cxx |  8 +++---
>  Source/cmBuildCommand.cxx                   | 25 +++++++++----------
>  Source/cmCLocaleEnvironmentScope.cxx        |  5 ++--
>  Source/cmCTest.cxx                          | 11 +++++----
>  Source/cmCommandArgumentParserHelper.cxx    |  8 +++---
>  Source/cmConditionEvaluator.cxx             |  2 +-
>  Source/cmExportCommand.cxx                  |  5 ++--
>  Source/cmExtraEclipseCDT4Generator.cxx      |  9 ++++---
>  Source/cmFileCommand.cxx                    | 11 +++++----
>  Source/cmFindPackageCommand.cxx             |  4 +--
>  Source/cmGlobalVisualStudio7Generator.cxx   |  6 ++---
>  Source/cmMakefile.cxx                       |  5 +++-
>  Source/cmNinjaTargetGenerator.cxx           |  2 +-
>  Source/cmQtAutoGenerators.cxx               |  2 +-
>  Source/cmSetCommand.cxx                     |  7 +++---
>  Source/cmState.cxx                          |  5 ++--
>  Source/cmSystemTools.cxx                    |  6 ++---
>  Source/cmTimestamp.cxx                      |  7 +++---
>  Source/cmUtils.hxx                          | 26 ++++++++++++++++++++
>  Source/cmake.cxx                            | 21 +++++-----------
>  Source/cmcmd.cxx                            | 16 +++++-------

Applied:

 Use better KWSys SystemTools::GetEnv and HasEnv signatures
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1f87a50

>  Source/kwsys/SystemInformation.cxx          | 20 +++++++--------

I dropped this one because it introduces a dependency
SystemInformation => SystemTools that was not there before
and I don't think we need this for the environment variables
it uses.

>  Source/kwsys/SystemTools.cxx                | 38 +++++++++++------------------
>  Source/kwsys/testSystemTools.cxx            |  9 ++++---

Applied to upstream KWSys first:

 http://review.source.kitware.com/21340

Thanks,
-Brad


From brad.king at kitware.com  Mon Jul 18 10:04:31 2016
From: brad.king at kitware.com (Brad King)
Date: Mon, 18 Jul 2016 10:04:31 -0400
Subject: [cmake-developers] [PATCH v4 4/4] For Windows encode process
 output to internally used encoding
In-Reply-To: <20160707215406.16180-4-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-4-davispuh@gmail.com>
Message-ID: <6487f0ec-3be6-8024-74a0-791952e46207@kitware.com>

On 07/07/2016 05:54 PM, D?vis Mos?ns wrote:
> Typically Windows applications (eg. MSVC compiler) use current console's
> codepage for output to pipes so we need to encode that to internally used
> encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
[snip]
>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
> +    cmsysProcess_DecodeTextOutput(cp, &data, &length);
[snip]
>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
> +    cmsysProcess_DecodeTextOutput(cp, &data, &length);

Unfortunately I don't think that pattern will work reliably because
a multi-byte character could be split across a buffering boundary
and therefore not decoded correctly.  We may need the consuming
contexts to collect the whole output before converting.

Also, I'd like to avoid modifying KWSys Process for this if possible
because it may be replaced by libuv so we need the conversion code
to be in CMake proper.

Thanks,
-Brad


From konstantin at podsvirov.pro  Mon Jul 18 14:17:45 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Mon, 18 Jul 2016 21:17:45 +0300
Subject: [cmake-developers] [Review Request][Draft] CMake project for QtIFW
Message-ID: <25141468865865@web4m.yandex.ru>

Hello guys!

I like CMake and Qt and i initial write and now support CPack IFW generator.

For more project integrations i create sugestion:
https://bugreports.qt.io/browse/QTIFW-876

And start work on it:
https://codereview.qt-project.org/#/c/165493

It's draft, but any feedback will be appreciated.

--
Regards,
Konstantin Podsvirov

From michael.stuermer at schaeffler.com  Tue Jul 19 11:43:36 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Tue, 19 Jul 2016 15:43:36 +0000
Subject: [cmake-developers] Improved WIX support
Message-ID: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>

Hello there,

in short:

I fixed some minor issues with WIX toolset support and added the possibility to integrate service installation/uninstallation with generated msi packages. Please review and comment what is missing for integration in upstream.

a bit longer:

When creating a component-based installer, the root component (or feature, as it is called in WIX context) cannot be named and described. This can now be done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION.

The install folder can only be set to a subfolder of ProgramFiles or ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it is now possible to set default installation paths on arbitrary locations such as "C:\myprogram". In order for this to work, the Guids of the WIX-Components must be explicitly set using CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are auto generated using the value "*".

Disabling components by default using the CPACK_COMPONENT_<component_name>_DISABLED is now working.

With the install file properties CPACK_WIX_KEYPATH and CPACK_WIX_PROPERTY_<tagname> it is now possible to add custom tags (such as service handling) to the installer. If the custom tag depends on several files within the directory, bundling of several files in WIX-Components is needed. This can be done using CPACK_WIX_BUNDLE_COMPONENTS.

All new functionalities are documented and some small example snippets are added to the documentation.

I hope these changes make sense to you, if the documentation is not accurate enough or the naming of cmake properties/variables should be changed please let me know

Best Regards

Michael St?rmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-improved-WIX-support.patch
Type: application/octet-stream
Size: 18378 bytes
Desc: 0001-improved-WIX-support.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160719/ec58702a/attachment.obj>

From c.vallicari at gmail.com  Tue Jul 19 13:46:50 2016
From: c.vallicari at gmail.com (Cyril VALLICARI)
Date: Tue, 19 Jul 2016 19:46:50 +0200
Subject: [cmake-developers] Security Report for CMake
Message-ID: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>

Hello,

While working on sqlitebrowser security (which use CMake) i've found that
the installer
 execute an unquoted command when it call for the uninstall command.

POC Screenshot in attached file

Which allow a Privilege Escalation as described here :
cwe.mitre.org/data/definitions/428.html

After diggin a little bit more with sqlitebrowser team we found out that
this line is the problem

https://github.com/Kitware/CMake/blob/master/Modules/NSIS.template.in#L916

This :
ExecWait '$0 _?=$3' ;Do not copy the uninstaller to a temp file
Should be :

+ ExecWait '"$0" _?=$3' ;Do not copy the uninstaller to a temp file
Here a Patch that correct the vulnerability

https://github.com/justinclift/CMake/commit/af65a04f690e1d6e6e2d3aa3467116689ab12b4f

We've test this it works fine and fully correct the vulnerability :)

If you ever reward such report let me know and please, if you can, credit
me for the report

Best Regards

Cyril Vallicari / Ug_0 Security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160719/108aa456/attachment-0001.html>

From brad.king at kitware.com  Tue Jul 19 16:29:57 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 19 Jul 2016 16:29:57 -0400
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
Message-ID: <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>

On 07/19/2016 01:46 PM, Cyril VALLICARI wrote:
> Here a Patch that correct the vulnerability 

Thanks, applied:

 NSIS: Quote uninstaller path when executing it in a shell
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01e1f694

-Brad


From c.vallicari at gmail.com  Tue Jul 19 19:41:14 2016
From: c.vallicari at gmail.com (Cyril VALLICARI)
Date: Wed, 20 Jul 2016 01:41:14 +0200
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <CAPc5cBVgbye1JE+8z-_eiO=t7RmUBowSJ-JM7iu8MfGgD+sLyQ@mail.gmail.com>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
 <CAPc5cBVgbye1JE+8z-_eiO=t7RmUBowSJ-JM7iu8MfGgD+sLyQ@mail.gmail.com>
Message-ID: <CAPc5cBXuFTK3WJR0egAh0W2w=4yQ9EhJvg0Y3y5jFZE8AaCvew@mail.gmail.com>

Ok cool, no reward i guess :-/

just please add my nickname Ug_0 Security and remove the mail adress of
public pages (it's ok for the mailing list i guess)

Also do you plan to request a CVE for this as CMake is very like very used
(i mean how many installer are affected in the wild ?)

Thank you

2016-07-19 23:47 GMT+02:00 Cyril VALLICARI <c.vallicari at gmail.com>:

> Ok cool, no reward i guess :-/
> just please add my nick name Ug_0 Security and remove the
>  mail adress thank you
>
> 2016-07-19 22:29 GMT+02:00 Brad King <brad.king at kitware.com>:
>
>> On 07/19/2016 01:46 PM, Cyril VALLICARI wrote:
>> > Here a Patch that correct the vulnerability
>>
>> Thanks, applied:
>>
>>  NSIS: Quote uninstaller path when executing it in a shell
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01e1f694
>>
>> -Brad
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/9aa524d1/attachment.html>

From justin at postgresql.org  Wed Jul 20 02:31:36 2016
From: justin at postgresql.org (Justin Clift)
Date: Wed, 20 Jul 2016 07:31:36 +0100
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
Message-ID: <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>

On 19 Jul 2016, at 21:29, Brad King <brad.king at kitware.com> wrote:
> On 07/19/2016 01:46 PM, Cyril VALLICARI wrote:
>> Here a Patch that correct the vulnerability 
> 
> Thanks, applied:
> 
> NSIS: Quote uninstaller path when executing it in a shell
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01e1f694
> 
> -Brad

Oops, it kind of looks like Cyril forgot to mention there could
be further problems in the same template file.  The initial line
was pointed out by Amir Szekely (NSIS project) as below, while we
were trying to figure out where the unquoted path problem in
sqlitebrowser's package was coming from. ;)

Amir pointed out there may be other locations with the same
unquoted path problem in the template.

In my testing for a solution for sqlitebrowser's package, the
one I fixed was definitely an issue, easily replicated.

I'm not sure where the unquoted registry string would be used from.
It didn't seem to be used as such from Windows Control Panel ->
Add/Remove Programs.  So, I ignored it. ;)

I don't know enough about CPack to know what other bits I may have
missed though, nor if that unquoted string in the registry could be
a problem in some other way.

Thoughts? :)

Regards and best wishes,

Justin Clift


Begin forwarded message:
> From: Amir Szekely <kichik at gmail.com>
> Subject: Re: Security report for NSIS
> Date: 15 July 2016 01:33:12 BST
> To: Cyril VALLICARI <c.vallicari at gmail.com>, justin at postgresql.org
> 
> This seems to be a bug in CPack:
> 
> https://github.com/Kitware/CMake/blob/master/Modules/NSIS.template.in#L916
> 
> That's the line where it executes the uninstaller without quotes. There may be more than one place.
> 
> They are also writing an unquoted string to to the registry:
> 
> https://github.com/Kitware/CMake/blob/master/Modules/NSIS.template.in#L655
> 
> For a quick fix, you can turn off CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL.
[snip]

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


From nilsgladitz at gmail.com  Wed Jul 20 06:02:58 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 20 Jul 2016 12:02:58 +0200
Subject: [cmake-developers] Improved WIX support
In-Reply-To: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
Message-ID: <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>

On 19.07.2016 17:43, Stuermer, Michael SP/HZA-ZSEP wrote:
> Hello there,
>
> in short:
>
> I fixed some minor issues with WIX toolset support and added the possibility to integrate service installation/uninstallation with generated msi packages. Please review and comment what is missing for integration in upstream.
>
> a bit longer:
>
> When creating a component-based installer, the root component (or feature, as it is called in WIX context) cannot be named and described. This can now be done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION.
>
> The install folder can only be set to a subfolder of ProgramFiles or ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it is now possible to set default installation paths on arbitrary locations such as "C:\myprogram". In order for this to work, the Guids of the WIX-Components must be explicitly set using CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are auto generated using the value "*".
>
> Disabling components by default using the CPACK_COMPONENT_<component_name>_DISABLED is now working.
>
> With the install file properties CPACK_WIX_KEYPATH and CPACK_WIX_PROPERTY_<tagname> it is now possible to add custom tags (such as service handling) to the installer. If the custom tag depends on several files within the directory, bundling of several files in WIX-Components is needed. This can be done using CPACK_WIX_BUNDLE_COMPONENTS.
>
> All new functionalities are documented and some small example snippets are added to the documentation.
>
> I hope these changes make sense to you, if the documentation is not accurate enough or the naming of cmake properties/variables should be changed please let me know

Would you mind dividing these changes into feature sized patches that I 
can review, test and integrate individually?

Thanks!
Nils

From michael.stuermer at schaeffler.com  Wed Jul 20 06:54:51 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Wed, 20 Jul 2016 10:54:51 +0000
Subject: [cmake-developers] Improved WIX support
In-Reply-To: <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
Message-ID: <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>

> -----Original Message-----
> From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
> Sent: Wednesday, July 20, 2016 12:03 PM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] Improved WIX support
> 
> On 19.07.2016 17:43, Stuermer, Michael SP/HZA-ZSEP wrote:
> > Hello there,
> >
> > in short:
> >
> > I fixed some minor issues with WIX toolset support and added the
> possibility to integrate service installation/uninstallation with generated msi
> packages. Please review and comment what is missing for integration in
> upstream.
> >
> > a bit longer:
> >
> > When creating a component-based installer, the root component (or
> feature, as it is called in WIX context) cannot be named and described. This
> can now be done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME
> and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION.
> >
> > The install folder can only be set to a subfolder of ProgramFiles or
> ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it is
> now possible to set default installation paths on arbitrary locations such as
> "C:\myprogram". In order for this to work, the Guids of the WIX-
> Components must be explicitly set using
> CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are
> auto generated using the value "*".
> >
> > Disabling components by default using the
> CPACK_COMPONENT_<component_name>_DISABLED is now working.
> >
> > With the install file properties CPACK_WIX_KEYPATH and
> CPACK_WIX_PROPERTY_<tagname> it is now possible to add custom tags
> (such as service handling) to the installer. If the custom tag depends on
> several files within the directory, bundling of several files in WIX-
> Components is needed. This can be done using
> CPACK_WIX_BUNDLE_COMPONENTS.
> >
> > All new functionalities are documented and some small example snippets
> are added to the documentation.
> >
> > I hope these changes make sense to you, if the documentation is not
> > accurate enough or the naming of cmake properties/variables should be
> > changed please let me know
> 
> Would you mind dividing these changes into feature sized patches that I can
> review, test and integrate individually?
> 

I hoped I could avoid this :-). Of course I can split it up.

Another thing: I just found out that I broke the patch-concept of the WIX generator and that using a patchfile supports adding service installation and handling. So I will remove the unnecessary features I added before submitting the splitted patches. Will take a little time.

> Thanks!
> Nils

Best Regards

Michael

From brad.king at kitware.com  Wed Jul 20 08:58:24 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 08:58:24 -0400
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
 <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>
Message-ID: <398b54a8-d932-243c-e574-aa3b25aa7d7e@kitware.com>

On 07/20/2016 02:31 AM, Justin Clift wrote:
> Amir pointed out there may be other locations with the same
> unquoted path problem in the template.

Thanks.  I'm not very familiar with NSIS or the syntax in the
template file so we'll be dependent on others to find/fix any
remaining problems.

Meanwhile I've revised the commit message to update the credits:

 NSIS: Quote uninstaller path when executing it in a shell
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=057f21ae

I've queued this for merge to 'release' for 3.6.1.

-Brad


From michael.stuermer at schaeffler.com  Wed Jul 20 09:58:44 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Wed, 20 Jul 2016 13:58:44 +0000
Subject: [cmake-developers] Improved WIX support
In-Reply-To: <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
Message-ID: <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>

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

best regrads,
Michael

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of Stuermer, Michael SP/HZA-ZSEP
> Sent: Wednesday, July 20, 2016 12:55 PM
> To: Nils Gladitz; CMake Developers
> Subject: Re: [cmake-developers] Improved WIX support
> 
> > -----Original Message-----
> > From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
> > Sent: Wednesday, July 20, 2016 12:03 PM
> > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> > Subject: Re: [cmake-developers] Improved WIX support
> >
> > On 19.07.2016 17:43, Stuermer, Michael SP/HZA-ZSEP wrote:
> > > Hello there,
> > >
> > > in short:
> > >
> > > I fixed some minor issues with WIX toolset support and added the
> > possibility to integrate service installation/uninstallation with
> > generated msi packages. Please review and comment what is missing for
> > integration in upstream.
> > >
> > > a bit longer:
> > >
> > > When creating a component-based installer, the root component (or
> > feature, as it is called in WIX context) cannot be named and
> > described. This can now be done using
> > CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME
> > and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION.
> > >
> > > The install folder can only be set to a subfolder of ProgramFiles or
> > ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it
> is
> > now possible to set default installation paths on arbitrary locations
> > such as "C:\myprogram". In order for this to work, the Guids of the
> > WIX- Components must be explicitly set using
> > CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are
> auto
> > generated using the value "*".
> > >
> > > Disabling components by default using the
> > CPACK_COMPONENT_<component_name>_DISABLED is now working.
> > >
> > > With the install file properties CPACK_WIX_KEYPATH and
> > CPACK_WIX_PROPERTY_<tagname> it is now possible to add custom tags
> > (such as service handling) to the installer. If the custom tag depends
> > on several files within the directory, bundling of several files in
> > WIX- Components is needed. This can be done using
> > CPACK_WIX_BUNDLE_COMPONENTS.
> > >
> > > All new functionalities are documented and some small example
> > > snippets
> > are added to the documentation.
> > >
> > > I hope these changes make sense to you, if the documentation is not
> > > accurate enough or the naming of cmake properties/variables should
> > > be changed please let me know
> >
> > Would you mind dividing these changes into feature sized patches that
> > I can review, test and integrate individually?
> >
> 
> I hoped I could avoid this :-). Of course I can split it up.
> 
> Another thing: I just found out that I broke the patch-concept of the WIX
> generator and that using a patchfile supports adding service installation and
> handling. So I will remove the unnecessary features I added before
> submitting the splitted patches. Will take a little time.
> 
> > Thanks!
> > Nils
> 
> Best Regards
> 
> Michael
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-added-support-for.patch
Type: application/octet-stream
Size: 2223 bytes
Desc: 0003-added-support-for.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/c531fdb4/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-added-support-for-CPACK_WIX_SKIP_PROGRAM_FOLDER-to-e.patch
Type: application/octet-stream
Size: 5634 bytes
Desc: 0004-added-support-for-CPACK_WIX_SKIP_PROGRAM_FOLDER-to-e.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/c531fdb4/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-added-support-for-patching-feature-components-i.e.-a.patch
Type: application/octet-stream
Size: 979 bytes
Desc: 0005-added-support-for-patching-feature-components-i.e.-a.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/c531fdb4/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-find-installed-files-also-if-they-are-prefixed-with-.patch
Type: application/octet-stream
Size: 1304 bytes
Desc: 0001-find-installed-files-also-if-they-are-prefixed-with-.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/c531fdb4/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-disabling-installer-components-for-WIX-now-working.patch
Type: application/octet-stream
Size: 852 bytes
Desc: 0002-disabling-installer-components-for-WIX-now-working.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/c531fdb4/attachment-0009.obj>

From brad.king at kitware.com  Wed Jul 20 10:27:02 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 10:27:02 -0400
Subject: [cmake-developers] [PATCH v4 3/4] Use SystemTools::GetEnv and
 HasEnv functions
In-Reply-To: <3ff37385-b716-d197-a5b9-0dc1d5595085@kitware.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-3-davispuh@gmail.com>
 <3ff37385-b716-d197-a5b9-0dc1d5595085@kitware.com>
Message-ID: <dd7193e4-f6fc-5975-d605-978afd685b72@kitware.com>

On 07/18/2016 10:00 AM, Brad King wrote:
> On 07/07/2016 05:54 PM, D?vis Mos?ns wrote:
>>  Source/kwsys/SystemTools.cxx                | 38 +++++++++++------------------
>>  Source/kwsys/testSystemTools.cxx            |  9 ++++---
> 
> Applied to upstream KWSys first:
> 
>  http://review.source.kitware.com/21340

This is now in KWSys `master`.  I've updated it in CMake:

 KWSys 2016-07-18 (19732229)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb7b5087

Thanks,
-Brad


From brad.king at kitware.com  Wed Jul 20 10:27:30 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 10:27:30 -0400
Subject: [cmake-developers] [PATCH v3 6/7] Use Windows version of
 Directory::Load for MinGW too
In-Reply-To: <20160706191213.16242-6-davispuh@gmail.com>
References: <20160706191213.16242-1-davispuh@gmail.com>
 <20160706191213.16242-6-davispuh@gmail.com>
Message-ID: <8222e03b-4882-9a60-37f0-a45b8f233ca1@kitware.com>

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

-Brad


From brad.king at kitware.com  Wed Jul 20 10:27:27 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 10:27:27 -0400
Subject: [cmake-developers] [PATCH v4 2/4] Deprecate const char*
 SystemTools::GetEnv function
In-Reply-To: <20160707215406.16180-2-davispuh@gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-2-davispuh@gmail.com>
Message-ID: <b93c3d90-913c-1c38-666a-14b22211fffd@kitware.com>

On 07/07/2016 05:54 PM, D?vis Mos?ns wrote:
>  Source/kwsys/SystemTools.hxx.in | 14 ++++++++++++--

Thanks.  Applied to KWSys first:

 http://review.source.kitware.com/21348

-Brad


From brad.king at kitware.com  Wed Jul 20 10:27:16 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 10:27:16 -0400
Subject: [cmake-developers] [PATCH v5 2/2] Add MinGW support for FStream
In-Reply-To: <9542e620-e746-117b-bcaf-a3d49f182ea8@kitware.com>
References: <20160717002210.31226-1-davispuh@gmail.com>
 <20160717002210.31226-2-davispuh@gmail.com>
 <9542e620-e746-117b-bcaf-a3d49f182ea8@kitware.com>
Message-ID: <570b6822-c698-6527-e95a-6449a4ee32cd@kitware.com>

On 07/18/2016 09:28 AM, Brad King wrote:
> Thanks.  I've added this and its parent commit to KWSys:
> 
>  http://review.source.kitware.com/21339

This is now in KWSys `master`.  I've updated it in CMake:

 KWSys 2016-07-19 (9d1dbd95)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ef2b2b1

Thanks,
-Brad


From brad.king at kitware.com  Wed Jul 20 10:44:01 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 10:44:01 -0400
Subject: [cmake-developers] [PATCH v4] For consoles output on Windows
 use our own std::streambuf
In-Reply-To: <20160710021230.10618-1-davispuh@gmail.com>
References: <20160706191213.16242-5-davispuh@gmail.com>
 <20160710021230.10618-1-davispuh@gmail.com>
Message-ID: <9138f8cc-71e5-b5e3-da21-1aa46c4143f0@kitware.com>

On 07/09/2016 10:12 PM, D?vis Mos?ns wrote:
>  int main(int ac, char const* const* av)
>  {
> +#if defined(_WIN32)
> +  // Replace streambuf so we can output Unicode to console
> +  cmsys::ConsoleBuf *cbufio = CM_NULLPTR;
> +  cmsys::ConsoleBuf *cbuferr = CM_NULLPTR;
> +  std::streambuf *coutbuf = std::cout.rdbuf();
> +  std::streambuf *cerrbuf = std::cerr.rdbuf();
> +  try {
> +    cbufio = new cmsys::ConsoleBuf();
> +    coutbuf = std::cout.rdbuf(cbufio);
> +    cbuferr = new cmsys::ConsoleBuf(true);
> +    cerrbuf = std::cerr.rdbuf(cbuferr);
> +  } catch (const std::runtime_error& ex) {
> +    std::cerr << "Failed to create ConsoleBuf!" << std::endl
> +              << ex.what() << std::endl;
> +  };
> +#endif
...
> +#if defined(_WIN32)
> +  if (cbufio) {
> +    delete cbufio;
> +    std::cout.rdbuf(coutbuf);
> +  }
> +  if (cbuferr) {
> +    delete cbuferr;
> +    std::cerr.rdbuf(cerrbuf);
> +  }
> +#endif

Please add to KWSys ConsoleBuf a RAII-style helper to perform
the above steps.  Its constructor can take either std::cout
or std:cerr by reference.

Also, please add a test case for this to KWSys itself.  The
test should at least be able to compile and run.  Verification
that output looks right may need to be a manual step though.

Thanks,
-Brad


From bballet at ivsweb.com  Wed Jul 20 11:22:55 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Wed, 20 Jul 2016 17:22:55 +0200
Subject: [cmake-developers] patch VS2010 generator : handle
	VS_GLOBAL_RootNamespace as well as VS_GLOBAL_ROOTNAMESPACE
Message-ID: <CAJoWGD2XoEAEicTYS1t_5JFt5Ei2oznVueYjoTAwSbG-j-bpBg@mail.gmail.com>

Hi folks,

As user I'm currently working on migrating C++CLI projects to CMake.

I wasted a few hours because I used VS_GLOBAL_RootNamespace (a specialized
version of VS_GLOBAL_<variable> property) instead of
VS_GLOBAL_ROOTNAMESPACE.

So here is a patch to save the next one from wasting those same hours.

In my opinion, VS_GLOBAL_ROOTNAMESPACE with VS_GLOBAL_PROJECT_TYPE and
VS_GLOBAL_KEYWORD should be tagged as deprecated and users should be
redirected to VS_GLOBAL_<variable>. It would be simpler.


-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/374eaab1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-VisualStudio10-generator-the-RootNamespace-property-.patch
Type: application/octet-stream
Size: 1217 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160720/374eaab1/attachment.obj>

From brad.king at kitware.com  Wed Jul 20 11:41:01 2016
From: brad.king at kitware.com (Brad King)
Date: Wed, 20 Jul 2016 11:41:01 -0400
Subject: [cmake-developers] patch VS2010 generator : handle
 VS_GLOBAL_RootNamespace as well as VS_GLOBAL_ROOTNAMESPACE
In-Reply-To: <CAJoWGD2XoEAEicTYS1t_5JFt5Ei2oznVueYjoTAwSbG-j-bpBg@mail.gmail.com>
References: <CAJoWGD2XoEAEicTYS1t_5JFt5Ei2oznVueYjoTAwSbG-j-bpBg@mail.gmail.com>
Message-ID: <f3f76640-2599-a92a-74e2-30ed296b646a@kitware.com>

On 07/20/2016 11:22 AM, Benjamin Ballet via cmake-developers wrote:
> I used VS_GLOBAL_RootNamespace (a specialized version of
> VS_GLOBAL_<variable> property) instead of VS_GLOBAL_ROOTNAMESPACE.
> 
> So here is a patch

Thanks, applied:

 VS: Handle VS_GLOBAL_RootNamespace special case
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8aa97fba

> In my opinion, VS_GLOBAL_ROOTNAMESPACE with VS_GLOBAL_PROJECT_TYPE
> and VS_GLOBAL_KEYWORD should be tagged as deprecated and users
> should be redirected to VS_GLOBAL_<variable>. It would be simpler.

Perhaps, though your patch would still be needed for the special
handling of RootNamespace.

Thanks,
-Brad


From nilsgladitz at gmail.com  Thu Jul 21 02:55:43 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 21 Jul 2016 08:55:43 +0200
Subject: [cmake-developers] [Patch 1/5] Improved WIX support
In-Reply-To: <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
Message-ID: <86ff32d4-eb74-9eee-fc52-cb613842a38d@gmail.com>

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

To start with I don't think I really like the first patch as it is.

We should either require that install file locations are canonical 
(which is what I went for when I initially implemented them; I think I 
would still prefer it that way),
or perform more complete and consistent canonicalization. e.g.

- The implementation as-is only works with cmake's internal path 
separation (forward slash).
     Given the canonical path "foo/bar" the path "foo\bar" does not 
currently work. So neither should a backslash work in a prefix e.g. 
".\foo/bar".
     I'd also like to think of these paths as portable (should any other 
CPack generator choose to implement install properties as well) which is 
why I think we should not support (canonicalize) windows path separators 
anywhere in the path.

- Handling "." only as a singular prefix is inconsistent.
     If we do implement this then ".." should also be supported and 
canonicalization should work anywhere in the path.
     e.g. given the canonical path "foo/bar/baz" these should refer to 
the same path:
         - "./foo/bar/baz"
         - "././foo/bar/baz"
         - "foo/./bar/baz"
         - "foo/../foo/bar/baz"
         etc.

Nils

From michael.stuermer at schaeffler.com  Thu Jul 21 04:00:21 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Thu, 21 Jul 2016 08:00:21 +0000
Subject: [cmake-developers] [Patch 1/5] Improved WIX support
In-Reply-To: <86ff32d4-eb74-9eee-fc52-cb613842a38d@gmail.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
 <86ff32d4-eb74-9eee-fc52-cb613842a38d@gmail.com>
Message-ID: <bb6a1e93180d4ef8a9bc019bcf2077e2@DE013666.schaeffler.com>



> -----Original Message-----
> From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
> Sent: Thursday, July 21, 2016 8:56 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 1/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 feedback,
> >
> 
> To start with I don't think I really like the first patch as it is.
> 
> We should either require that install file locations are canonical (which is what
> I went for when I initially implemented them; I think I would still prefer it that
> way), or perform more complete and consistent canonicalization. e.g.
> 
> - The implementation as-is only works with cmake's internal path separation
> (forward slash).
>      Given the canonical path "foo/bar" the path "foo\bar" does not currently
> work. So neither should a backslash work in a prefix e.g.
> ".\foo/bar".
>      I'd also like to think of these paths as portable (should any other CPack
> generator choose to implement install properties as well) which is why I think
> we should not support (canonicalize) windows path separators anywhere in
> the path.
> 
> - Handling "." only as a singular prefix is inconsistent.
>      If we do implement this then ".." should also be supported and
> canonicalization should work anywhere in the path.
>      e.g. given the canonical path "foo/bar/baz" these should refer to the same
> path:
>          - "./foo/bar/baz"
>          - "././foo/bar/baz"
>          - "foo/./bar/baz"
>          - "foo/../foo/bar/baz"
>          etc.
> 
> Nils

Thanks for the detailed feedback! Proper canonicalization when setting up the map of installed files is a better way to go. I just had the impression the key of the file in the map ("./foo", "foo", ...) should not be changed. If this is not the case and we can change/improve the canonicalization where the installed files are set up we can discard this patch and I'll have a look at it again in the future.

For my current task I do not need the install properties anymore, so there is no dependency to this patch from the others.

Michael

From bballet at ivsweb.com  Thu Jul 21 04:52:04 2016
From: bballet at ivsweb.com (Benjamin Ballet)
Date: Thu, 21 Jul 2016 10:52:04 +0200
Subject: [cmake-developers] patch bugfix : CMAKE_VS_PLATFORM_TOOLSET not
	defined for VisualStudio 2010
Message-ID: <CAJoWGD3cdexRX+SYFMGV4jS2Z+2YR6+iXiM_XeLw616zPcdVRw@mail.gmail.com>

Hi,

I stumbled on a bug : CMAKE_VS_PLATFORM_TOOLSET is empty when generating
for VisualStudio 2010

Here is a patch

-- 
*Benjamin BALLET*
Ing?nieur R&D

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard T?l* :  01 44 69 37 37
*>* www.activisu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160721/b82081e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-VS-set-DefaultPlatformToolset-to-v100-for-VisualStud.patch
Type: application/octet-stream
Size: 936 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160721/b82081e4/attachment.obj>

From justin at postgresql.org  Thu Jul 21 05:01:51 2016
From: justin at postgresql.org (Justin Clift)
Date: Thu, 21 Jul 2016 10:01:51 +0100
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <398b54a8-d932-243c-e574-aa3b25aa7d7e@kitware.com>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
 <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>
 <398b54a8-d932-243c-e574-aa3b25aa7d7e@kitware.com>
Message-ID: <9EE39E89-C7CC-4BC9-A6FB-AA3375ACE8CA@postgresql.org>

On 20 Jul 2016, at 13:58, Brad King <brad.king at kitware.com> wrote:
> On 07/20/2016 02:31 AM, Justin Clift wrote:
>> Amir pointed out there may be other locations with the same
>> unquoted path problem in the template.
> 
> Thanks.  I'm not very familiar with NSIS or the syntax in the
> template file so we'll be dependent on others to find/fix any
> remaining problems.

k.  Are there people who could be proactively reached out to, or
is it more of a "pray and hope for the best" thing? :)


> Meanwhile I've revised the commit message to update the credits:
> 
> NSIS: Quote uninstaller path when executing it in a shell
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=057f21ae
> 
> I've queued this for merge to 'release' for 3.6.1.

Cool.  Is there an ETA for that?

Asking because until then, every Windows installer generated by
CMake with CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL enabled will
be bundling a local privilege escalation to Admin.

While that's not "the sky is falling" stuff... ;) it seems like
something better fixed sooner rather than later.

Cyril's question about a CVE is valid too.  This should probably
be written up. :)

Do you guys want to do that, or should Cyril begin the process?

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


From brad.king at kitware.com  Thu Jul 21 10:14:22 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 10:14:22 -0400
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <9EE39E89-C7CC-4BC9-A6FB-AA3375ACE8CA@postgresql.org>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
 <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>
 <398b54a8-d932-243c-e574-aa3b25aa7d7e@kitware.com>
 <9EE39E89-C7CC-4BC9-A6FB-AA3375ACE8CA@postgresql.org>
Message-ID: <5035ad7c-3d3f-860f-ba34-99d464cc971a@kitware.com>

On 07/21/2016 05:01 AM, Justin Clift wrote:
> Are there people who could be proactively reached out to, or
> is it more of a "pray and hope for the best" thing? :)

The latter.  If someone familiar with the syntax can add
precautionary quotes in places they are allowed but missing
that may help.

>> I've queued this for merge to 'release' for 3.6.1.
> 
> Cool.  Is there an ETA for that?

I'm working to get it out as soon as possible.

> Windows installer generated by
> CMake with CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL enabled will
> be bundling a local privilege escalation to Admin.

I've revised the commit again to add this information to the
commit message and the release notes:

 NSIS: Quote uninstaller path when executing it in a shell
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11768733

> Cyril's question about a CVE is valid too.  This should probably
> be written up. :)
> 
> Do you guys want to do that, or should Cyril begin the process?

Please begin one.  As now mentioned in the above commit message
this option was added in CMake 2.8.9 (which was released around
August 2012).

Fortunately CMake's own installers never used this option.

Thanks,
-Brad

From nilsgladitz at gmail.com  Thu Jul 21 10:45:17 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 21 Jul 2016 16:45:17 +0200
Subject: [cmake-developers] [Patch 2/5] Improved WIX support
In-Reply-To: <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
Message-ID: <c65fda5a-caeb-8582-95ed-ea268fd7d15a@gmail.com>

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 feedback,
>
> best regrads,
> Michael

I've merged patch 2 implementing CPACK_COMPONENT_<COMPONENT>_DISABLED to 
"next" for testing:
     https://cmake.org/gitweb?p=cmake.git;a=commit;h=4c52c4c2

I amended the commit message and added the otherwise missing release note.

Nils

From brad.king at kitware.com  Thu Jul 21 11:23:58 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 11:23:58 -0400
Subject: [cmake-developers] patch bugfix : CMAKE_VS_PLATFORM_TOOLSET not
 defined for VisualStudio 2010
In-Reply-To: <CAJoWGD3cdexRX+SYFMGV4jS2Z+2YR6+iXiM_XeLw616zPcdVRw@mail.gmail.com>
References: <CAJoWGD3cdexRX+SYFMGV4jS2Z+2YR6+iXiM_XeLw616zPcdVRw@mail.gmail.com>
Message-ID: <6b525164-c540-d0e9-a78c-e54cd3a51d1e@kitware.com>

On 07/21/2016 04:52 AM, Benjamin Ballet via cmake-developers wrote:
> Here is a patch

Thanks, applied:

 VS: Explicitly default to v100 toolset in Visual Studio 2010
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=059c230d

-Brad


From brad.king at kitware.com  Thu Jul 21 11:32:04 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 11:32:04 -0400
Subject: [cmake-developers] [Patch 2/5] Improved WIX support
In-Reply-To: <c65fda5a-caeb-8582-95ed-ea268fd7d15a@gmail.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
 <c65fda5a-caeb-8582-95ed-ea268fd7d15a@gmail.com>
Message-ID: <f1603cfa-63bc-88fd-3c78-c6ca5e3b0fd6@kitware.com>

On 07/21/2016 10:45 AM, Nils Gladitz wrote:
> I amended the commit message and added the otherwise missing release note.

Thanks.  Currently the release note is:

> +* The CPack WIX generator now supports CPACK_COMPONENT_<COMPONENT>_DISABLED.
> +  This can be used to deselect a component from being installed by default.

However, that option is not publicly documented as a variable for projects
to set.  Instead it is the internal representation of the `DISABLED` option
to `cpack_add_component`.  Please revise the commit message to reference
this command (as :command:`cpack_add_component`).

Thanks,
-Brad


From brad.king at kitware.com  Thu Jul 21 11:40:03 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 11:40:03 -0400
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <571A28FE.6080401@kitware.com>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
Message-ID: <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>

On 04/22/2016 09:37 AM, Brad King wrote:
> The rest of the changes are now in 'master'.  Thanks for working on this!

Unfortunately I've had to revert some of these changes due to
regressions they cause.  See issue here:

  https://gitlab.kitware.com/cmake/cmake/issues/16209

-Brad


From justin at postgresql.org  Thu Jul 21 11:49:47 2016
From: justin at postgresql.org (Justin Clift)
Date: Thu, 21 Jul 2016 16:49:47 +0100
Subject: [cmake-developers] Security Report for CMake
In-Reply-To: <5035ad7c-3d3f-860f-ba34-99d464cc971a@kitware.com>
References: <CAPc5cBWcjXGWVZdCBVwzdj1CeYeVNeXpEwj=wMvi_ktS9GGAmA@mail.gmail.com>
 <733e6eec-49e4-a488-c1b7-25c9dd060b51@kitware.com>
 <5B943371-07DC-4D61-827F-161FA100B3C0@postgresql.org>
 <398b54a8-d932-243c-e574-aa3b25aa7d7e@kitware.com>
 <9EE39E89-C7CC-4BC9-A6FB-AA3375ACE8CA@postgresql.org>
 <5035ad7c-3d3f-860f-ba34-99d464cc971a@kitware.com>
Message-ID: <659CFF8E-B3E5-44C8-8070-2E483C70122F@postgresql.org>

On 21 Jul 2016, at 15:14, Brad King <brad.king at kitware.com> wrote:
> On 07/21/2016 05:01 AM, Justin Clift wrote:
>> Are there people who could be proactively reached out to, or
>> is it more of a "pray and hope for the best" thing? :)
> 
> The latter.  If someone familiar with the syntax can add
> precautionary quotes in places they are allowed but missing
> that may help.

k.  I've just emailed the people on the git history for the
template file, asking if any of them have the time+skill to
assist.  Lets hope. :)

<snip>
> I've revised the commit again to add this information to the
> commit message and the release notes:
> 
> NSIS: Quote uninstaller path when executing it in a shell
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11768733
> 
>> Cyril's question about a CVE is valid too.  This should probably
>> be written up. :)
>> 
>> Do you guys want to do that, or should Cyril begin the process?
> 
> Please begin one.  As now mentioned in the above commit message
> this option was added in CMake 2.8.9 (which was released around
> August 2012).

Cool, thats good info for the CVE.  I'll help Cyril with that if
he needs it. :)


> Fortunately CMake's own installers never used this option.

They should be safe to after this. :D

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


From seblist at xwmw.org  Thu Jul 21 11:50:02 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Thu, 21 Jul 2016 17:50:02 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
Message-ID: <cf11efee-787a-212d-9360-8ecea97de628@xwmw.org>

Am 21.07.2016 um 17:40 schrieb Brad King:
> On 04/22/2016 09:37 AM, Brad King wrote:
>> The rest of the changes are now in 'master'.  Thanks for working on this!
>
> Unfortunately I've had to revert some of these changes due to
> regressions they cause.  See issue here:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16209
>

I've seen it.
At the moment I'm busy but I'll try to look at it next week.

-Sebastian



From nilsgladitz at gmail.com  Thu Jul 21 12:08:34 2016
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Thu, 21 Jul 2016 18:08:34 +0200
Subject: [cmake-developers] [Patch 2/5] Improved WIX support
In-Reply-To: <f1603cfa-63bc-88fd-3c78-c6ca5e3b0fd6@kitware.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
 <c65fda5a-caeb-8582-95ed-ea268fd7d15a@gmail.com>
 <f1603cfa-63bc-88fd-3c78-c6ca5e3b0fd6@kitware.com>
Message-ID: <852a23ef-a966-d669-81b1-48af1e713f1f@gmail.com>

On 21.07.2016 17:32, Brad King wrote:
> On 07/21/2016 10:45 AM, Nils Gladitz wrote:
>> I amended the commit message and added the otherwise missing release note.
> Thanks.  Currently the release note is:
>
>> +* The CPack WIX generator now supports CPACK_COMPONENT_<COMPONENT>_DISABLED.
>> +  This can be used to deselect a component from being installed by default.
> However, that option is not publicly documented as a variable for projects
> to set.  Instead it is the internal representation of the `DISABLED` option
> to `cpack_add_component`.  Please revise the commit message to reference
> this command (as :command:`cpack_add_component`).

 From CPack's point of view the CPACK_* variables are the public interface.
cpack_add_component() (and CPackComponent.cmake) are only involved when 
you use cmake to generate the cpack configuration.

So perhaps the variable should be documented instead?

CPACK_COMPONENT_<COMPONENT>_DISABLED being undocumented might be an 
oversight to begin with given that e.g. 
"CPACK_COMPONENT_<compName>_REQUIRED" is documented (also settable 
through cpack_add_component()).

Nils

From davispuh at gmail.com  Thu Jul 21 13:22:56 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Thu, 21 Jul 2016 20:22:56 +0300
Subject: [cmake-developers] [PATCH v5] For Windows encode process output to
	internally used encoding
In-Reply-To: <20160707215406.16180-4-davispuh@gmail.com>
References: <20160707215406.16180-4-davispuh@gmail.com>
Message-ID: <20160721172258.4366-1-davispuh@gmail.com>

Typically Windows applications (eg. MSVC compiler) use current console's
codepage for output to pipes so we need to encode that to internally used
encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
---
 Source/cmExecProgramCommand.cxx    |  3 ++
 Source/cmExecuteProcessCommand.cxx | 11 ++++-
 Source/cmProcessTools.cxx          |  9 +++-
 Source/cmSystemTools.cxx           | 11 ++++-
 Source/kwsys/CMakeLists.txt        |  2 +-
 Source/kwsys/ProcessOutput.hxx.in  | 94 ++++++++++++++++++++++++++++++++++++++
 Source/kwsys/SystemInformation.cxx |  4 ++
 bootstrap                          |  1 +
 8 files changed, 128 insertions(+), 7 deletions(-)
 create mode 100644 Source/kwsys/ProcessOutput.hxx.in

diff --git a/Source/cmExecProgramCommand.cxx b/Source/cmExecProgramCommand.cxx
index 58bbc31..217cda1 100644
--- a/Source/cmExecProgramCommand.cxx
+++ b/Source/cmExecProgramCommand.cxx
@@ -14,6 +14,7 @@
 #include "cmSystemTools.h"
 
 #include <cmsys/Process.h>
+#include <cmsys/ProcessOutput.hxx>
 
 // cmExecProgramCommand
 bool cmExecProgramCommand::InitialPass(std::vector<std::string> const& args,
@@ -219,6 +220,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, std::string& output,
   int length;
   char* data;
   int p;
+  cmsys::ProcessOutput processOutput;
   while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     if (p == cmsysProcess_Pipe_STDOUT || p == cmsysProcess_Pipe_STDERR) {
       if (verbose) {
@@ -230,6 +232,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, std::string& output,
 
   // All output has been read.  Wait for the process to exit.
   cmsysProcess_WaitForExit(cp, CM_NULLPTR);
+  processOutput.DecodeText(output, output);
 
   // Check the result of running the process.
   std::string msg;
diff --git a/Source/cmExecuteProcessCommand.cxx b/Source/cmExecuteProcessCommand.cxx
index d97b25f..bdefa8b 100644
--- a/Source/cmExecuteProcessCommand.cxx
+++ b/Source/cmExecuteProcessCommand.cxx
@@ -14,6 +14,7 @@
 #include "cmSystemTools.h"
 
 #include <cmsys/Process.h>
+#include <cmsys/ProcessOutput.hxx>
 
 #include <ctype.h> /* isspace */
 
@@ -228,17 +229,21 @@ bool cmExecuteProcessCommand::InitialPass(std::vector<std::string> const& args,
   int length;
   char* data;
   int p;
+  cmsys::ProcessOutput processOutput;
+  std::string strdata;
   while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     // Put the output in the right place.
     if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
       if (output_variable.empty()) {
-        cmSystemTools::Stdout(data, length);
+        processOutput.DecodeText(data, length, strdata);
+        cmSystemTools::Stdout(strdata.c_str(), strdata.size());
       } else {
         cmExecuteProcessCommandAppend(tempOutput, data, length);
       }
     } else if (p == cmsysProcess_Pipe_STDERR && !error_quiet) {
       if (error_variable.empty()) {
-        cmSystemTools::Stderr(data, length);
+        processOutput.DecodeText(data, length, strdata);
+        cmSystemTools::Stderr(strdata.c_str(), strdata.size());
       } else {
         cmExecuteProcessCommandAppend(tempError, data, length);
       }
@@ -247,6 +252,8 @@ bool cmExecuteProcessCommand::InitialPass(std::vector<std::string> const& args,
 
   // All output has been read.  Wait for the process to exit.
   cmsysProcess_WaitForExit(cp, CM_NULLPTR);
+  processOutput.DecodeText(tempOutput, tempOutput);
+  processOutput.DecodeText(tempError, tempError);
 
   // Fix the text in the output strings.
   cmExecuteProcessCommandFixText(tempOutput, output_strip_trailing_whitespace);
diff --git a/Source/cmProcessTools.cxx b/Source/cmProcessTools.cxx
index 34b8df2..fdfa276 100644
--- a/Source/cmProcessTools.cxx
+++ b/Source/cmProcessTools.cxx
@@ -12,6 +12,7 @@
 #include "cmProcessTools.h"
 
 #include <cmsys/Process.h>
+#include <cmsys/ProcessOutput.hxx>
 
 void cmProcessTools::RunProcess(struct cmsysProcess_s* cp, OutputParser* out,
                                 OutputParser* err)
@@ -20,14 +21,18 @@ void cmProcessTools::RunProcess(struct cmsysProcess_s* cp, OutputParser* out,
   char* data = CM_NULLPTR;
   int length = 0;
   int p;
+  cmsys::ProcessOutput processOutput;
+  std::string strdata;
   while ((out || err) &&
          (p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     if (out && p == cmsysProcess_Pipe_STDOUT) {
-      if (!out->Process(data, length)) {
+      processOutput.DecodeText(data, length, strdata);
+      if (!out->Process(strdata.c_str(), int(strdata.size()))) {
         out = CM_NULLPTR;
       }
     } else if (err && p == cmsysProcess_Pipe_STDERR) {
-      if (!err->Process(data, length)) {
+      processOutput.DecodeText(data, length, strdata);
+      if (!err->Process(strdata.c_str(), int(strdata.size()))) {
         err = CM_NULLPTR;
       }
     }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 9740ef7..ca92646 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -26,6 +26,7 @@
 #include <cmsys/Glob.hxx>
 #include <cmsys/RegularExpression.hxx>
 #include <cmsys/System.h>
+#include <cmsys/ProcessOutput.hxx>
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmArchiveWrite.h"
 #include "cmLocale.h"
@@ -612,6 +613,8 @@ bool cmSystemTools::RunSingleCommand(std::vector<std::string> const& command,
   char* data;
   int length;
   int pipe;
+  cmsys::ProcessOutput processOutput;
+  std::string strdata;
   if (outputflag != OUTPUT_PASSTHROUGH &&
       (captureStdOut || captureStdErr || outputflag != OUTPUT_NONE)) {
     while ((pipe = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR)) >
@@ -627,14 +630,16 @@ bool cmSystemTools::RunSingleCommand(std::vector<std::string> const& command,
 
       if (pipe == cmsysProcess_Pipe_STDOUT) {
         if (outputflag != OUTPUT_NONE) {
-          cmSystemTools::Stdout(data, length);
+          processOutput.DecodeText(data, length, strdata);
+          cmSystemTools::Stdout(strdata.c_str(), strdata.size());
         }
         if (captureStdOut) {
           tempStdOut.insert(tempStdOut.end(), data, data + length);
         }
       } else if (pipe == cmsysProcess_Pipe_STDERR) {
         if (outputflag != OUTPUT_NONE) {
-          cmSystemTools::Stderr(data, length);
+          processOutput.DecodeText(data, length, strdata);
+          cmSystemTools::Stderr(strdata.c_str(), strdata.size());
         }
         if (captureStdErr) {
           tempStdErr.insert(tempStdErr.end(), data, data + length);
@@ -646,9 +651,11 @@ bool cmSystemTools::RunSingleCommand(std::vector<std::string> const& command,
   cmsysProcess_WaitForExit(cp, CM_NULLPTR);
   if (captureStdOut) {
     captureStdOut->assign(tempStdOut.begin(), tempStdOut.end());
+    processOutput.DecodeText(*captureStdOut, *captureStdOut);
   }
   if (captureStdErr) {
     captureStdErr->assign(tempStdErr.begin(), tempStdErr.end());
+    processOutput.DecodeText(*captureStdErr, *captureStdErr);
   }
 
   bool result = true;
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 87f6048..5fce50f 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -666,7 +666,7 @@ ENDIF()
 # selected components.  Initialize with required components.
 SET(KWSYS_CLASSES)
 SET(KWSYS_H_FILES Configure SharedForward)
-SET(KWSYS_HXX_FILES Configure String
+SET(KWSYS_HXX_FILES Configure String ProcessOutput
   hashtable hash_fun hash_map hash_set
   )
 
diff --git a/Source/kwsys/ProcessOutput.hxx.in b/Source/kwsys/ProcessOutput.hxx.in
new file mode 100644
index 0000000..a662bed
--- /dev/null
+++ b/Source/kwsys/ProcessOutput.hxx.in
@@ -0,0 +1,94 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef @KWSYS_NAMESPACE at _ProcessOutput_hxx
+#define @KWSYS_NAMESPACE at _ProcessOutput_hxx
+
+#include <string>
+#include <vector>
+#if defined(_WIN32)
+#  ifndef WIN32_LEAN_AND_MEAN
+#    define WIN32_LEAN_AND_MEAN 1
+#  endif
+#  include <windows.h>
+#endif
+
+namespace @KWSYS_NAMESPACE@
+{
+  class ProcessOutput
+  {
+    public:
+#if defined(_WIN32)
+      static const UINT defaultCodepage = @KWSYS_ENCODING_DEFAULT_CODEPAGE@;
+#endif
+      ProcessOutput()
+      {
+#if defined(_WIN32)
+        codepage = GetConsoleCP();
+        if (!codepage) {
+          codepage = GetACP();
+        }
+#endif
+      }
+
+      ~ProcessOutput()
+      {
+      }
+
+      bool DecodeText(std::string raw, std::string& decoded)
+      {
+        bool success = true;
+        decoded = raw;
+#if defined(_WIN32)
+        if (raw.size() > 0 && codepage != defaultCodepage) {
+          success = false;
+          const int wlength = MultiByteToWideChar(codepage, 0, raw.c_str(), int(raw.size()), NULL, 0);
+          wchar_t* wdata = new wchar_t[wlength];
+          int r = MultiByteToWideChar(codepage, 0, raw.c_str(), int(raw.size()), wdata, wlength);
+          if (r > 0) {
+            int length = WideCharToMultiByte(defaultCodepage, 0, wdata, wlength, NULL, 0, NULL, NULL);
+            char *data = new char[length + 1];
+            r = WideCharToMultiByte(defaultCodepage, 0, wdata, wlength, data, length, NULL, NULL);
+            if (r > 0) {
+              data[length] = '\0';
+              decoded = data;
+              success = true;
+            }
+            delete[] data;
+          }
+          delete[] wdata;
+        }
+#endif
+        return success;
+      }
+
+      bool DecodeText(const char* data, size_t length, std::string& decoded)
+      {
+        return DecodeText(std::string(data, length), decoded);
+      }
+
+      bool DecodeText(std::vector<char> raw, std::vector<char>& decoded)
+      {
+         std::string str;
+         const bool success = DecodeText(std::string(raw.begin(), raw.end()), str);
+         decoded.assign(str.begin(), str.end());
+         return success;
+      }
+
+    private:
+#if defined(_WIN32)
+      UINT codepage;
+#endif
+  };
+}
+
+#endif
+
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 81fb2f9..d5495de 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -37,12 +37,14 @@
 #include "kwsysPrivate.h"
 #include KWSYS_HEADER(SystemInformation.hxx)
 #include KWSYS_HEADER(Process.h)
+#include KWSYS_HEADER(ProcessOutput.hxx)
 
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
 #if 0
 # include "SystemInformation.hxx.in"
 # include "Process.h.in"
+# include "ProcessOutput.hxx.in"
 #endif
 
 #include <iostream>
@@ -4631,6 +4633,7 @@ std::string SystemInformationImplementation::RunProcess(std::vector<const char*>
   int length;
   double timeout = 255;
   int pipe; // pipe id as returned by kwsysProcess_WaitForData()
+  ProcessOutput processOutput;
 
   while( ( static_cast<void>(pipe = kwsysProcess_WaitForData(gp,&data,&length,&timeout)),
            (pipe == kwsysProcess_Pipe_STDOUT || pipe == kwsysProcess_Pipe_STDERR) ) ) // wait for 1s
@@ -4638,6 +4641,7 @@ std::string SystemInformationImplementation::RunProcess(std::vector<const char*>
       buffer.append(data, length);
     }
   kwsysProcess_WaitForExit(gp, 0);
+  processOutput.DecodeText(buffer, buffer);
 
   int result = 0;
   switch(kwsysProcess_GetState(gp))
diff --git a/bootstrap b/bootstrap
index 742fa2b..aa7307d 100755
--- a/bootstrap
+++ b/bootstrap
@@ -371,6 +371,7 @@ KWSYS_FILES="\
   FStream.hxx \
   Glob.hxx \
   Process.h \
+  ProcessOutput.hxx \
   RegularExpression.hxx \
   String.h \
   String.hxx \
-- 
2.9.0


From davispuh at gmail.com  Thu Jul 21 13:36:27 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Thu, 21 Jul 2016 20:36:27 +0300
Subject: [cmake-developers] [PATCH v4 4/4] For Windows encode process
 output to internally used encoding
In-Reply-To: <6487f0ec-3be6-8024-74a0-791952e46207@kitware.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-4-davispuh@gmail.com>
 <6487f0ec-3be6-8024-74a0-791952e46207@kitware.com>
Message-ID: <CAOE4rSzbVTg5FV7XELQe5RTGStYj65gJb0EWSKXdkCS0iOLe7A@mail.gmail.com>

2016-07-18 17:04 GMT+03:00 Brad King <brad.king at kitware.com>:
> On 07/07/2016 05:54 PM, D?vis Mos?ns wrote:
>> Typically Windows applications (eg. MSVC compiler) use current console's
>> codepage for output to pipes so we need to encode that to internally used
>> encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
> [snip]
>>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>> +    cmsysProcess_DecodeTextOutput(cp, &data, &length);
> [snip]
>>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>> +    cmsysProcess_DecodeTextOutput(cp, &data, &length);
>
> Unfortunately I don't think that pattern will work reliably because
> a multi-byte character could be split across a buffering boundary
> and therefore not decoded correctly.  We may need the consuming
> contexts to collect the whole output before converting.
>

That's true, but only for MBCS code pages, it will work fine for SBCS and DBCS
(if buffer size is even). I think this issue would appear very rarely.
Anyway I improved this in places where it was easy, but in some places it's
more complicated...

For example

   while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     // Put the output in the right place.
     if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
       if (output_variable.empty()) {
         cmSystemTools::Stdout(data, length);

Here we output buffer immediately.

 while ((out || err) &&
          (p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
     if (out && p == cmsysProcess_Pipe_STDOUT) {
       if (!out->Process(data, length)) {

and also here we process buffer immediately.

From brad.king at kitware.com  Thu Jul 21 13:46:54 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 13:46:54 -0400
Subject: [cmake-developers] [PATCH v4 4/4] For Windows encode process
 output to internally used encoding
In-Reply-To: <CAOE4rSzbVTg5FV7XELQe5RTGStYj65gJb0EWSKXdkCS0iOLe7A@mail.gmail.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-4-davispuh@gmail.com>
 <6487f0ec-3be6-8024-74a0-791952e46207@kitware.com>
 <CAOE4rSzbVTg5FV7XELQe5RTGStYj65gJb0EWSKXdkCS0iOLe7A@mail.gmail.com>
Message-ID: <50c7aa80-72ec-686f-932b-e51b87700b4b@kitware.com>

On 07/21/2016 01:36 PM, D?vis Mos?ns wrote:
> Anyway I improved this in places where it was easy, but in some places it's
> more complicated...
> 
> For example
> 
>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>      // Put the output in the right place.
>      if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
>        if (output_variable.empty()) {
>          cmSystemTools::Stdout(data, length);
> 
> Here we output buffer immediately.
> 
>  while ((out || err) &&
>           (p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>      if (out && p == cmsysProcess_Pipe_STDOUT) {
>        if (!out->Process(data, length)) {

In such cases the data need to be piped through a buffered decoder
that can keep partial fragments around between updates.

Does MultiByteToWideChar or some other API have a way to detect
such boundaries?

-Brad


From brad.king at kitware.com  Thu Jul 21 13:48:11 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 13:48:11 -0400
Subject: [cmake-developers] [PATCH v5] For Windows encode process output
 to internally used encoding
In-Reply-To: <20160721172258.4366-1-davispuh@gmail.com>
References: <20160707215406.16180-4-davispuh@gmail.com>
 <20160721172258.4366-1-davispuh@gmail.com>
Message-ID: <1e07ff7f-b3ba-dd42-4fa9-efcb9486d8fe@kitware.com>

On 07/21/2016 01:22 PM, D?vis Mos?ns wrote:
> +namespace @KWSYS_NAMESPACE@
> +{
> +  class ProcessOutput
> +  {

Let's just add this to CMake proper first.  The one use case in
KWSys SystemInformation is not really necessary because it is
only in code paths used on non-Windows systems.  We can always
move this to KWSys later.

> +      bool DecodeText(std::string raw, std::string& decoded)
> +      {
> +        bool success = true;
> +        decoded = raw;
> +#if defined(_WIN32)
> +        if (raw.size() > 0 && codepage != defaultCodepage) {
> +          success = false;
> +          const int wlength = MultiByteToWideChar(codepage, 0, raw.c_str(), int(raw.size()), NULL, 0);

Why do we need new calls to MultiByteToWideChar instead of
having clients just directly use kwsysEncoding_mbstowcs?

This may become moot given the buffer boundary problems
discussed in another branch of this thread.

-Brad

From brad.king at kitware.com  Thu Jul 21 13:48:19 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 21 Jul 2016 13:48:19 -0400
Subject: [cmake-developers] [Patch 2/5] Improved WIX support
In-Reply-To: <852a23ef-a966-d669-81b1-48af1e713f1f@gmail.com>
References: <f1fb0cd195ed452c9280891fa9f97087@DE013666.schaeffler.com>
 <bb2436fb-936c-539e-d228-a268afd81fd0@gmail.com>
 <f59942953b9a493895a056c2823fa214@DE013666.schaeffler.com>
 <e187860ef12c45d69e68f55285d27bdb@DE013666.schaeffler.com>
 <c65fda5a-caeb-8582-95ed-ea268fd7d15a@gmail.com>
 <f1603cfa-63bc-88fd-3c78-c6ca5e3b0fd6@kitware.com>
 <852a23ef-a966-d669-81b1-48af1e713f1f@gmail.com>
Message-ID: <1831f167-4fe7-93f1-2a76-bd80a5458c86@kitware.com>

On 07/21/2016 12:08 PM, Nils Gladitz wrote:
> So perhaps the variable should be documented instead?

Yes, thanks.  Then rebase on that and revise the release
note to link it with :variable:`...`.

-Brad


From Tobias.Hunger at qt.io  Thu Jul 21 08:53:19 2016
From: Tobias.Hunger at qt.io (Tobias Hunger)
Date: Thu, 21 Jul 2016 12:53:19 +0000
Subject: [cmake-developers] cmake -E capabilities [attempt 2]
Message-ID: <1469105598.765.32.camel@qt.io>

Hello fellow developers,

https://github.com/hunger/CMake/commits/cmake-capabilities

has my attempt to get "cmake -E capabilities" merged -- in preparation of the
server mode.

Brad already merged a big chunk of the changes, but he wanted to see the extra
generator registration cleaned up before continuing. That has happened in the
new push: The first patch adds a cmExternalMakefileProjectGeneratorFactory,
which has all the necessary information so that cmake no longer needs to create
instances of all extra generators during startup.

Extra generators can now alias others -- which is used for the KDevelop3
generator. Maybe we can just remove that? The comments claim the generator is
for compatibility with cmake 2.2. That would shave a couple of lines of that
patch...

The capabilities work on top of that branch is mostly unchanged, but exposes an
"isAlias" flag. I now suppress all aliases in the output of -E capabilities ?as
I think it makes no sense to have new code announce compatibility bridges (and
the last version already hardcoded KDevelop3 to be suppressed).

Best Regards,
Tobias

-- 
Tobias Hunger,?Senior?Software Engineer?| The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From davispuh at gmail.com  Thu Jul 21 20:43:05 2016
From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=)
Date: Fri, 22 Jul 2016 03:43:05 +0300
Subject: [cmake-developers] [PATCH v4 4/4] For Windows encode process
 output to internally used encoding
In-Reply-To: <50c7aa80-72ec-686f-932b-e51b87700b4b@kitware.com>
References: <20160707215406.16180-1-davispuh@gmail.com>
 <20160707215406.16180-4-davispuh@gmail.com>
 <6487f0ec-3be6-8024-74a0-791952e46207@kitware.com>
 <CAOE4rSzbVTg5FV7XELQe5RTGStYj65gJb0EWSKXdkCS0iOLe7A@mail.gmail.com>
 <50c7aa80-72ec-686f-932b-e51b87700b4b@kitware.com>
Message-ID: <CAOE4rSyKA_Jb1Sh_izQdr==WapG3QuaqYOqW-7AmuYPw4H9+iw@mail.gmail.com>

2016-07-21 20:46 GMT+03:00 Brad King <brad.king at kitware.com>:
> On 07/21/2016 01:36 PM, D?vis Mos?ns wrote:
>> Anyway I improved this in places where it was easy, but in some places it's
>> more complicated...
>>
>> For example
>>
>>    while ((p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>>      // Put the output in the right place.
>>      if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
>>        if (output_variable.empty()) {
>>          cmSystemTools::Stdout(data, length);
>>
>> Here we output buffer immediately.
>>
>>  while ((out || err) &&
>>           (p = cmsysProcess_WaitForData(cp, &data, &length, CM_NULLPTR), p)) {
>>      if (out && p == cmsysProcess_Pipe_STDOUT) {
>>        if (!out->Process(data, length)) {
>
> In such cases the data need to be piped through a buffered decoder
> that can keep partial fragments around between updates.
>
> Does MultiByteToWideChar or some other API have a way to detect
> such boundaries?

As far as I know in WinAPI there isn't any such function.
With MultiByteToWideChar such partial char would be replaced with ? (U+003F)
or ? (U+FFFD).

We would need to use some library or implement this ourselves.
In WinAPI there's CharPrevExA and IsDBCSLeadByteEx (or GetCPInfo) which we can
use and implement this easily for 1-2 byte code pages but it doesn't work for
code pages where character can be more than 2 bytes, eg. UTF-8. Those would
need to be handled separately.
Also could check if last character is ? and try again with one byte less.


Using EnumSystemCodePages and GetCPInfoEx I collected info about all supported
code pages on my Windows 10

https://paste.kde.org/pthwqdbxv/rjwgwd/raw

Code pages where MaxCharSize is more than 1 and UseLeadByte is No need special
handling for those depending on that particular encoding.

>> +      bool DecodeText(std::string raw, std::string& decoded)
>> +      {
>> +        bool success = true;
>> +        decoded = raw;
>> +#if defined(_WIN32)
>> +        if (raw.size() > 0 && codepage != defaultCodepage) {
>> +          success = false;
>> +          const int wlength = MultiByteToWideChar(codepage, 0, raw.c_str(), int(raw.size()), NULL, 0);
>
> Why do we need new calls to MultiByteToWideChar instead of
> having clients just directly use kwsysEncoding_mbstowcs?
>

Because from WaitForData we're getting data and length, and I assume that data
might not be null-terminated but kwsysEncoding_mbstowcs expects source to be
null-terminated and doesn't accept length.

From dl.soluz at gmx.net  Fri Jul 22 00:38:09 2016
From: dl.soluz at gmx.net (Dennis Luehring)
Date: Fri, 22 Jul 2016 06:38:09 +0200
Subject: [cmake-developers] C# with CMake
Message-ID: <db19aa69-6a53-2b1b-6b7e-bdb1d31acae6@gmx.net>

any status update for the CMake C# Generator?

read thorugh "C# support ready for review"
https://cmake.org/pipermail/cmake-developers/2016-March/027911.html

seem to be still active:
https://github.com/micst/CMake/tree/csharp




From michael.stuermer at schaeffler.com  Fri Jul 22 03:03:01 2016
From: michael.stuermer at schaeffler.com (Stuermer, Michael  SP/HZA-ZSEP)
Date: Fri, 22 Jul 2016 07:03:01 +0000
Subject: [cmake-developers] C# with CMake
In-Reply-To: <db19aa69-6a53-2b1b-6b7e-bdb1d31acae6@gmx.net>
References: <db19aa69-6a53-2b1b-6b7e-bdb1d31acae6@gmx.net>
Message-ID: <e85c218127134f07a133d57f5e5f2de5@DE013666.schaeffler.com>

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of Dennis Luehring
> Sent: Friday, July 22, 2016 6:38 AM
> To: cmake-developers at cmake.org
> Subject: [cmake-developers] C# with CMake
> 
> any status update for the CMake C# Generator?
> 
> read thorugh "C# support ready for review"
> https://cmake.org/pipermail/cmake-developers/2016-March/027911.html
> 
> seem to be still active:
> https://github.com/micst/CMake/tree/csharp
> 
> 
> 
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

unfortunately not. I try to keep my fork up to date with kitwares master for easy merging, but I don't have time for more right now.

The main part missing (hopefully) is a proper compiler detection as mentioned by Brad:

https://cmake.org/pipermail/cmake-developers/2016-March/027945.html

Help in implementing proper compiler detection would be greatly appreciated, I will continue on this as soon as I can (but it can be months until then).


Best Regards

Michael St?rmer

From robert.maynard at kitware.com  Fri Jul 22 11:35:21 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 22 Jul 2016 11:35:21 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.1 available for download
Message-ID: <CAFzjYVotgVJvuCUaRhu2NKPuXP4TMRcCmZDO4ySqSR4ycBLCmA@mail.gmail.com>

We are pleased to announce that CMake 3.6.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

* The CPack NSIS generator's configuration file template was fixed
  to quote the path to the uninstaller tool used by the
  "CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL" option. This avoids
  depending on an insecure Windows feature to run an uninstaller tool
  with a space in the path.

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.6.1 since 3.6.0:

Alex Turbov (1):
      CPack/RPM: Add missed CPACK_RPM_FILE_NAME fallback variable

Brad King (6):
      Restore find_(library|file|path) search of PATH itself
      VS: Fix VS 2015 .vcxproj debug setting for v90 toolset (#15986)
      Ninja: Do not force response files when no sysconf(3) limit is used
      CPack: Add compatibility for incorrect CPACK_INSTALL_CMAKE_PROJECTS value
      Autogen: Revert changes to generate moc/rcc in subdirectories
      CMake 3.6.1

Chuck Atkins (3):
      FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac
      FindHDF5: Properly fail when required components are not found.
      FindHDF5: Cleanup inconsistent use of HDF5_ROOT

Justin Clift (1):
      NSIS: Quote uninstaller path when executing it in a shell

From ryan at raytheon.com  Fri Jul 22 16:24:23 2016
From: ryan at raytheon.com (Ryan D Retting)
Date: Fri, 22 Jul 2016 13:24:23 -0700
Subject: [cmake-developers] "Run ranlib on archives only if the tool is
	available" not in 3.6.1 release
Message-ID: <OF6B0EF6EB.C65BA4B9-ON88257FF8.006FFF88-88257FF8.00701900@raytheon.com>



Hi,
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.
Is there any reason this isn't getting pulled into an official release?

Run ranlib on archives only if the tool is available
https://github.com/Kitware/CMake/commit/ea59867187e8bdb8a7ffda37ad58e7f8493ebf7c



I'm working as a WindRiver customer to get VxWorks support working w/
cross-compiling and this is blocking me.
I've been able to get past this with cmake-3.6.20160620-g4835c-win64-x64
since it included the fix.  But, I've been waiting to use an official
release.

Thanks,
-Ryan

Raytheon
Ryan Retting
Senior Principal Software Engineer
Certified Raytheon Software Architect
Space & Airborne Systems
El Segundo, CA
310-334-4721
Ryan at Raytheon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160722/0369d95a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21539620.gif
Type: image/gif
Size: 481 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160722/0369d95a/attachment.gif>

From Stephen.Sorley at jhuapl.edu  Fri Jul 22 18:08:19 2016
From: Stephen.Sorley at jhuapl.edu (Sorley, Stephen L.)
Date: Fri, 22 Jul 2016 22:08:19 +0000
Subject: [cmake-developers] Spurious warning with FindCUDA.cmake on Windows
Message-ID: <ec25da12162c4f2ba4ea53284e069af8@APLEX03.dom1.jhuapl.edu>

Found a minor problem with FindCUDA.cmake on the master branch.  When using FindCUDA.cmake on Windows with CUDA SDK version 6.5 or older, CMake prints the following warning:

CMake Warning at cmake/FindCUDA.cmake:826 (message):
  Expecting to find librt for libcudart_static, but didn't find it.
Call Stack (most recent call first):
 cmake/build_setup.cmake:693 (find_package)
  CMakeLists.txt:42 (include)

This warning is incorrect, since librt is only present on Linux.  I've attached a patch (based on master) that fixes the problem.

Thanks!
Stephen S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160722/35c0ce59/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-for-spurious-CMake-warning-message-on-Windows.patch
Type: application/octet-stream
Size: 994 bytes
Desc: 0001-Fix-for-spurious-CMake-warning-message-on-Windows.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160722/35c0ce59/attachment.obj>

From tobias.hunger at gmail.com  Tue Jul 26 02:53:04 2016
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Tue, 26 Jul 2016 08:53:04 +0200
Subject: [cmake-developers] cmake -E capabilities [attempt 2]
In-Reply-To: <1469105598.765.32.camel@qt.io>
References: <1469105598.765.32.camel@qt.io>
Message-ID: <CAMdWP3E=UsXceRzb+L9C3gq-162_Nd+ZJdq9s=bNSe=ot3=XJA@mail.gmail.com>

Did anyone find some time for a review yet?

Best regards,
Tobias

Am 22.07.2016 01:37 schrieb "Tobias Hunger" <Tobias.Hunger at qt.io>:

> Hello fellow developers,
>
> https://github.com/hunger/CMake/commits/cmake-capabilities
>
> has my attempt to get "cmake -E capabilities" merged -- in preparation of
> the
> server mode.
>
> Brad already merged a big chunk of the changes, but he wanted to see the
> extra
> generator registration cleaned up before continuing. That has happened in
> the
> new push: The first patch adds a cmExternalMakefileProjectGeneratorFactory,
> which has all the necessary information so that cmake no longer needs to
> create
> instances of all extra generators during startup.
>
> Extra generators can now alias others -- which is used for the KDevelop3
> generator. Maybe we can just remove that? The comments claim the generator
> is
> for compatibility with cmake 2.2. That would shave a couple of lines of
> that
> patch...
>
> The capabilities work on top of that branch is mostly unchanged, but
> exposes an
> "isAlias" flag. I now suppress all aliases in the output of -E
> capabilities  as
> I think it makes no sense to have new code announce compatibility bridges
> (and
> the last version already hardcoded KDevelop3 to be suppressed).
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> 144331 B
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160726/245184c6/attachment.html>

From charles.huet at gmail.com  Tue Jul 26 03:04:33 2016
From: charles.huet at gmail.com (Charles Huet)
Date: Tue, 26 Jul 2016 07:04:33 +0000
Subject: [cmake-developers] Question over language bindings / daemon
In-Reply-To: <1468845145.765.21.camel@qt.io>
References: <CAMMCZ5P69My6xpbbf1NS0PFLi6Ys2CnYqZ_CyH5TS7-hxG8KjQ@mail.gmail.com>
 <1468845145.765.21.camel@qt.io>
Message-ID: <CAGTK6maZXjb3XvnDuEAMy_uLBdg09OPp=Xc-qEX7Mvu=2CHhfg@mail.gmail.com>

Hi Rick,

this is something I played with a bit, and while it is completely possible
to make your own little python binding, it will not be merged into CMake,
which means you will have to maintain it on your side.
Also, you will need to write the whole interface yourself, as the current
CMake lib API is not meant to be used in such a way.

While I too am more familiar and at ease with python and its ecosystem, lua
is a better fit for CMake as it can be redistribued easily (just one C file
to add to the build).
This would allow for better control of the updates, avoiding potential
conflicts with the installed version on the system and so on.

My Proof of concept can be found easily, but it will remain in this
unfinished state for ever, since when I'll get time to work on this I will
pursue the Lua angle.

Best,
Charles


Le lun. 18 juil. 2016 ? 14:47, Tobias Hunger <Tobias.Hunger at qt.io> a ?crit :

> Hi Rick,
>
> On Mo, 2016-07-18 at 00:59 +0100, RW via cmake-developers wrote:
> > Question 1
> > Will the new daemon mode if it's included have all the commands
> associated
> > with a CMakeFile?
> > (In other-words could I write a python library that could just pipe
> > commands into it, instead of generating a separate CMakeFile)
>
> It's server mode now:-)
>
> No, daemon mode will provide commands to query the build graph etc., but
> it will
> not be usable to feed CMakeLists.txt-commands to cmake one by one.
>
> > Question 2
> > I had a look at the way the functions are written within the code
> > while I could extract a list of them using something like CppSharp (for
> > example to extract a list of everything that inherits from cmCommand)
> > There doesn't seem to be any metadata that describes arguments that are
> > passed into a given function. (only that each function takes a vector of
> > strings).
> > Do you know if there's any xml or associated metadata (perhaps used to
> > generate the docs) for which arguments are associated with a given
> function?
>
> This in turn is in scope for server mode (not at the start, but later):
> That
> information is a by-product of the idea of server mode helping IDEs with
> code-
> completion of CMakeLists.txt files.
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> 144331 B
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160726/472bba91/attachment.html>

From seblist at xwmw.org  Tue Jul 26 11:31:00 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Tue, 26 Jul 2016 17:31:00 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
Message-ID: <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>

Am 21.07.2016 um 17:40 schrieb Brad King:
> On 04/22/2016 09:37 AM, Brad King wrote:
>> The rest of the changes are now in 'master'.  Thanks for working on this!
>
> Unfortunately I've had to revert some of these changes due to
> regressions they cause.  See issue here:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16209

Hi,
I have prepared an other approach which uses checksum suffixes
instead of nested directory generation.
This was tested on my Debian/amd64/Makefile setup.

-- From the commit:
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
--

Please review.

-Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: autogen_patch_2016-07-26-1.patch
Type: text/x-patch
Size: 18170 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160726/2134fa91/attachment-0001.bin>

From ben.boeckel at kitware.com  Tue Jul 26 11:53:16 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 26 Jul 2016 11:53:16 -0400
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
Message-ID: <20160726155316.GD14126@rotor>

On Tue, Jul 26, 2016 at 17:31:00 +0200, Sebastian Holtermann wrote:
> I have prepared an other approach which uses checksum suffixes
> instead of nested directory generation.
> This was tested on my Debian/amd64/Makefile setup.

Interesting; I like it. Might be worthwhile to reuse it for the .o files
in the future as well (since these can conflict, but are much less
likely to do so).

> Please review.

Could you run clang-format over the code? There are a number of style
issues that it will fix (IIRC, it needs at least Clang 3.8; I'm unsure
what version of the clang that comes with Xcode is sufficient).

> +    rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase( qrcSourceName,
> +      makefile->GetCurrentSourceDirectory(),
> +      makefile->GetCurrentBinaryDirectory(),
> +      makefile->GetHomeDirectory(),
> +      makefile->GetHomeOutputDirectory() );

Is there a reason we can't pass just the `makefile` down and have it
query all the parameters rather than having 5 arguments?

> +      struct TPair {
> +        const std::string * dir;
> +        const char * seed;
> +      };
> +      TPair pDirs[4] = {
> +        { &parenDirCSource, "CurrentSource" },
> +        { &parenDirCBinary, "CurrentBinary" },
> +        { &parenDirPSource, "ProjectSource" },
> +        { &parenDirPBinary, "ProjectBinary" }
> +      };
> +      TPair * itc = &pDirs[0];
> +      TPair * ite = &pDirs[0] + ( sizeof ( pDirs ) / sizeof ( TPair ) );

It might be better to just use a NULL sentinel at the end of the array.
If not, the extra spaces here should go away.

> +  // Calculate the file ( seed + relative path + name ) checksum
> +  std::string checksumBase64;
> +  {
> +    ::std::vector<unsigned char>hashBytes;

CMake just uses std::, not ::std::.

> +    {
> +      // Acquire hex value hash string
> +      std::string hexHash = cmCryptoHash::New("SHA256")->HashString(
> +            (sourceRelSeed+sourceRelPath+sourceFileName).c_str());
> +      // Convert hex value string to bytes
> +      hashBytes.resize ( hexHash.size()/2 );
> +      for ( unsigned int ii=0; ii != hashBytes.size(); ++ii ) {
> +        unsigned char byte ( 0 );
> +        for ( unsigned int jj=0; jj != 2; ++jj ) {
> +          unsigned char cval ( 0 );
> +          switch ( hexHash[ii*2+jj] ) {
> +          case '0': cval=0; break; case '1': cval=1; break;
> +          case '2': cval=2; break; case '3': cval=3; break;
> +          case '4': cval=4; break; case '5': cval=5; break;
> +          case '6': cval=6; break; case '7': cval=7; break;
> +          case '8': cval=8; break; case '9': cval=9; break;
> +          case 'a': cval=10; break; case 'b': cval=11; break;
> +          case 'c': cval=12; break; case 'd': cval=13; break;
> +          case 'e': cval=14; break; case 'f': cval=15; break;
> +          default: break;

I feel like this is better as:

    int nibble = hexHash[ii * 2 + jj];
    if ('0' <= nibble && nibble <= '9') {
        cval = nibble - '0';
    } else if ('a' <= nibble && nibble <= 'f') {
        cval = nibble - 'a' + 10;
    } else {
        // internal error about an unexpected hexchar
    }

Alternatively, cmUuid::IntFromHexDigit() (and possibly other methods)
could be refactored to allow this to share an implementation.

--Ben

From seblist at xwmw.org  Tue Jul 26 17:38:34 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Tue, 26 Jul 2016 23:38:34 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <20160726155316.GD14126@rotor>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
Message-ID: <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>

Thanks for the feedback.

>> I have prepared an other approach which uses checksum suffixes
>> instead of nested directory generation.
>> This was tested on my Debian/amd64/Makefile setup.
>
> Interesting; I like it. Might be worthwhile to reuse it for the .o files
> in the future as well (since these can conflict, but are much less
> likely to do so).
>
>> Please review.
>
> Could you run clang-format over the code? There are a number of style
> issues that it will fix (IIRC, it needs at least Clang 3.8; I'm unsure
> what version of the clang that comes with Xcode is sufficient).

I didn't knew clang-format. That's a powerful tool!
I have applied clang-format-3.8 which is available in Debian/Stretch.

>> +    rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase( qrcSourceName,
>> +      makefile->GetCurrentSourceDirectory(),
>> +      makefile->GetCurrentBinaryDirectory(),
>> +      makefile->GetHomeDirectory(),
>> +      makefile->GetHomeOutputDirectory() );
>
> Is there a reason we can't pass just the `makefile` down and have it
> query all the parameters rather than having 5 arguments?

In fact there is.
cmQtAutoGeneratorUtil::BuildFileBase is shared between
cmQtAutoGeneratorInitializer and cmQtAutoGenerators.
Both hold the directory names in different variables
which is why they must be passed manually.

>> +      struct TPair {
>> +        const std::string * dir;
>> +        const char * seed;
>> +      };
>> +      TPair pDirs[4] = {
>> +        { &parenDirCSource, "CurrentSource" },
>> +        { &parenDirCBinary, "CurrentBinary" },
>> +        { &parenDirPSource, "ProjectSource" },
>> +        { &parenDirPBinary, "ProjectBinary" }
>> +      };
>> +      TPair * itc = &pDirs[0];
>> +      TPair * ite = &pDirs[0] + ( sizeof ( pDirs ) / sizeof ( TPair ) );
>
> It might be better to just use a NULL sentinel at the end of the array.
> If not, the extra spaces here should go away.

I have changed that to use a NULL sentinel.
std::array would be the best solution IMO but it is not allowed, is it?

>> +  // Calculate the file ( seed + relative path + name ) checksum
>> +  std::string checksumBase64;
>> +  {
>> +    ::std::vector<unsigned char>hashBytes;
>
> CMake just uses std::, not ::std::.

Changed.

>> +    {
>> +      // Acquire hex value hash string
>> +      std::string hexHash = cmCryptoHash::New("SHA256")->HashString(
>> +            (sourceRelSeed+sourceRelPath+sourceFileName).c_str());
>> +      // Convert hex value string to bytes
>> +      hashBytes.resize ( hexHash.size()/2 );
>> +      for ( unsigned int ii=0; ii != hashBytes.size(); ++ii ) {
>> +        unsigned char byte ( 0 );
>> +        for ( unsigned int jj=0; jj != 2; ++jj ) {
>> +          unsigned char cval ( 0 );
>> +          switch ( hexHash[ii*2+jj] ) {
>> +          case '0': cval=0; break; case '1': cval=1; break;
>> +          case '2': cval=2; break; case '3': cval=3; break;
>> +          case '4': cval=4; break; case '5': cval=5; break;
>> +          case '6': cval=6; break; case '7': cval=7; break;
>> +          case '8': cval=8; break; case '9': cval=9; break;
>> +          case 'a': cval=10; break; case 'b': cval=11; break;
>> +          case 'c': cval=12; break; case 'd': cval=13; break;
>> +          case 'e': cval=14; break; case 'f': cval=15; break;
>> +          default: break;
>
> I feel like this is better as:
>
>     int nibble = hexHash[ii * 2 + jj];
>     if ('0' <= nibble && nibble <= '9') {
>         cval = nibble - '0';
>     } else if ('a' <= nibble && nibble <= 'f') {
>         cval = nibble - 'a' + 10;
>     } else {
>         // internal error about an unexpected hexchar
>     }
>
> Alternatively, cmUuid::IntFromHexDigit() (and possibly other methods)
> could be refactored to allow this to share an implementation.

I've changed it to the nibble version.
There also was a bit shift error (1 vs 4).
Doing so I found that Base64 allows '+' and '/' as characters which is 
bad for directory names obviously.
For now these characters get replaced with 'A' and 'B'.

If this technique gets wider use using Base58 might be a better choice. 
But it is not available in CMake, yet.

-Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: autogen_patch_2016-07-26-2.patch
Type: text/x-patch
Size: 18375 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160726/8208fbc1/attachment.bin>

From steveire at gmail.com  Tue Jul 26 17:42:12 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 26 Jul 2016 23:42:12 +0200
Subject: [cmake-developers] Autogen subdirectories patches
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
Message-ID: <nn8lfk$i98$1@ger.gmane.org>

Sebastian Holtermann wrote:

>> It might be better to just use a NULL sentinel at the end of the array.
>> If not, the extra spaces here should go away.
> 
> I have changed that to use a NULL sentinel.
> std::array would be the best solution IMO but it is not allowed, is it?

You could use cmArrayBegin and cmArrayEnd without the sentinal. They are 
designed for this kind of thing.

Thanks,

Steve.



From steveire at gmail.com  Tue Jul 26 19:11:46 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Wed, 27 Jul 2016 01:11:46 +0200
Subject: [cmake-developers] cmake -E capabilities [attempt 2]
References: <1469105598.765.32.camel@qt.io>
 <CAMdWP3E=UsXceRzb+L9C3gq-162_Nd+ZJdq9s=bNSe=ot3=XJA@mail.gmail.com>
Message-ID: <nn8qni$4g1$1@ger.gmane.org>

Tobias Hunger wrote:

> Did anyone find some time for a review yet?

Hi Tobias,

I had a look through this this evening. Thanks for working on this. The 
commit adding the functionality at the end looks much better after the extra 
generator refactoring. 

Here are some review notes:

* That commit has a cmDefinitions include though that should be removed.
* There are also some methods that should be const
* and a whitespace change that should be squashed into the commit that 
introduces it
* The pretty-print flag should be removed. Aside from being a boolean trap, 
it creates a interface segregation principle violation. See eg  

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23f87e81

for more.  If you want to pretty print things on the command line I suggest 

 cmake -E capabilities | jq

which will give you colorized output, or 

 cmake -E capabilities | python -mjson.tool

for something that you already have installed. See 

 http://stackoverflow.com/questions/352098/how-can-i-pretty-print-json

for more.

* The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the 
capabilities handling:

#if defined(CMAKE_BUILD_WITH_CMAKE)
    else if (args[1] == "capabilities") {
      cmake cm;
      std::cout << cm.ReportCapabilities();
      return 0;
    }
#endif

That define should not be used in ReportCapabilities.

* Splitting the 'CMake: Refactor ExtraGenerator registration' commit into 
multiple commits would make it more reviewable, and more bisectable in the 
future.

As it is, it is doing many different things, none of which are mentioned in 
the commit message, and some of which it probably shouldn't be doing. 

For example renaming GetExtraGeneratorName to 
GetExternalMakefileProjectGeneratorName is probably not needed. If you 
really want to do it, then it should be in its own commit with its own 
commit message which justifies the change. As it is, it adds noise to the 
big commit and makes it harder to review. Minimal is always better with 
commits which do refactoring like that.

A general good rule of thumb (which helps reviews, and makes things 
bisectable in the future) is to do one thing per commit.

Thanks,

Steve.



From ben.boeckel at kitware.com  Wed Jul 27 11:11:57 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 27 Jul 2016 11:11:57 -0400
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
Message-ID: <20160727151157.GA30225@megas.kitware.com>

On Tue, Jul 26, 2016 at 23:38:34 +0200, Sebastian Holtermann wrote:
> Doing so I found that Base64 allows '+' and '/' as characters which is 
> bad for directory names obviously.
> For now these characters get replaced with 'A' and 'B'.

'_' and '@' would be better replacements (with comments why they are
used) since 'A' and 'B' are already characters in Base64.

> +            // unexpected hexchar

This raise an internal error, not just be a comment.

> +          }
> +        }
> +        hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
> +      }
> +    }
> +    // Convert hash bytes to Base64 text string
> +    {
> +      std::vector<unsigned char> base64Bytes(hashBytes.size() * 2, 0);
> +      cmsysBase64_Encode(&hashBytes[0], hashBytes.size(), &base64Bytes[0], 0);
> +      checksumBase64 = reinterpret_cast<const char*>(&base64Bytes[0]);
> +      // Base64 allows '+' and '/' characters. Replace these.

This comment should indicate it is because the string is used as part of
a path and that these characters tend to cause problems in paths.

--Ben

From seblist at xwmw.org  Wed Jul 27 11:49:40 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Wed, 27 Jul 2016 17:49:40 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <20160727151157.GA30225@megas.kitware.com>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
 <20160727151157.GA30225@megas.kitware.com>
Message-ID: <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>


>> Doing so I found that Base64 allows '+' and '/' as characters which is
>> bad for directory names obviously.
>> For now these characters get replaced with 'A' and 'B'.
>
> '_' and '@' would be better replacements (with comments why they are
> used) since 'A' and 'B' are already characters in Base64.

Some quick research (aka googling) revealed
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278
It seems '_' and '-' are safer choices.

>> +            // unexpected hexchar
>
> This raise an internal error, not just be a comment.

Is there an error exit function in CMake?
Or just exit(-1);

>> +          }
>> +        }
>> +        hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
>> +      }
>> +    }
>> +    // Convert hash bytes to Base64 text string
>> +    {
>> +      std::vector<unsigned char> base64Bytes(hashBytes.size() * 2, 0);
>> +      cmsysBase64_Encode(&hashBytes[0], hashBytes.size(), &base64Bytes[0], 0);
>> +      checksumBase64 = reinterpret_cast<const char*>(&base64Bytes[0]);
>> +      // Base64 allows '+' and '/' characters. Replace these.
>
> This comment should indicate it is because the string is used as part of
> a path and that these characters tend to cause problems in paths.

Ok.

-Sebastian


From seblist at xwmw.org  Wed Jul 27 12:52:15 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Wed, 27 Jul 2016 18:52:15 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
 <20160727151157.GA30225@megas.kitware.com>
 <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>
Message-ID: <29289d0b-4489-5ab3-63cf-b65c2261dde6@xwmw.org>

Am 27.07.2016 um 17:49 schrieb Sebastian Holtermann:
>
>>> Doing so I found that Base64 allows '+' and '/' as characters which is
>>> bad for directory names obviously.
>>> For now these characters get replaced with 'A' and 'B'.
>>
>> '_' and '@' would be better replacements (with comments why they are
>> used) since 'A' and 'B' are already characters in Base64.
>
> Some quick research (aka googling) revealed
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278
>
> It seems '_' and '-' are safer choices.
>
>>> +            // unexpected hexchar
>>
>> This raise an internal error, not just be a comment.
>
> Is there an error exit function in CMake?
> Or just exit(-1);
>
>>> +          }
>>> +        }
>>> +        hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
>>> +      }
>>> +    }
>>> +    // Convert hash bytes to Base64 text string
>>> +    {
>>> +      std::vector<unsigned char> base64Bytes(hashBytes.size() * 2, 0);
>>> +      cmsysBase64_Encode(&hashBytes[0], hashBytes.size(),
>>> &base64Bytes[0], 0);
>>> +      checksumBase64 = reinterpret_cast<const char*>(&base64Bytes[0]);
>>> +      // Base64 allows '+' and '/' characters. Replace these.
>>
>> This comment should indicate it is because the string is used as part of
>> a path and that these characters tend to cause problems in paths.
>
> Ok.
>

The patch.

-Sebastian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: autogen_patch_2016-07-27-1.patch
Type: text/x-patch
Size: 18574 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160727/f4d9b8aa/attachment.bin>

From davispuh at gmail.com  Wed Jul 27 12:54:04 2016
From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=)
Date: Wed, 27 Jul 2016 19:54:04 +0300
Subject: [cmake-developers] [PATCH v5] For consoles output on Windows use
	our own std::streambuf
In-Reply-To: <20160710021230.10618-1-davispuh@gmail.com>
References: <20160710021230.10618-1-davispuh@gmail.com>
Message-ID: <20160727165405.22242-1-davispuh@gmail.com>

Currently Microsoft's C++ libraries implementation of std::cout/cerr
can't output Unicode characters but only ASCII or ANSI if locale is set
so we implement and use our own ConsoleBuf which can output Unicode
characters to console and it doesn't matter what locale or console's
codepage is set.
---
 CMakeLists.txt                       |   1 +
 Source/cmakemain.cxx                 |   6 +
 Source/kwsys/CMakeLists.txt          |  17 +-
 Source/kwsys/ConsoleBuf.hxx.in       | 318 ++++++++++++++++++++++++++
 Source/kwsys/testConsoleBuf.cxx      | 424 +++++++++++++++++++++++++++++++++++
 Source/kwsys/testConsoleBuf.hxx      |  25 +++
 Source/kwsys/testConsoleBufChild.cxx |  59 +++++
 bootstrap                            |   1 +
 8 files changed, 850 insertions(+), 1 deletion(-)
 create mode 100644 Source/kwsys/ConsoleBuf.hxx.in
 create mode 100644 Source/kwsys/testConsoleBuf.cxx
 create mode 100644 Source/kwsys/testConsoleBuf.hxx
 create mode 100644 Source/kwsys/testConsoleBufChild.cxx

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ae5990e..792b5a5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -258,6 +258,7 @@ macro (CMAKE_BUILD_UTILITIES)
   set(KWSYS_USE_MD5 1)
   set(KWSYS_USE_Process 1)
   set(KWSYS_USE_CommandLineArguments 1)
+  set(KWSYS_USE_ConsoleBuf 1)
   set(KWSYS_HEADER_ROOT ${CMake_BINARY_DIR}/Source)
   set(KWSYS_INSTALL_DOC_DIR "${CMAKE_DOC_DIR}")
   add_subdirectory(Source/kwsys)
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index 521a5bf..8b10d50 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -26,6 +26,7 @@
 #include "cmake.h"
 #include "cmcmd.h"
 #include <cmsys/Encoding.hxx>
+#include <cmsys/ConsoleBuf.hxx>
 
 #ifdef CMAKE_BUILD_WITH_CMAKE
 static const char* cmDocumentationName[][2] = {
@@ -153,6 +154,11 @@ static void cmakemainProgressCallback(const char* m, float prog,
 
 int main(int ac, char const* const* av)
 {
+#if defined(_WIN32)
+  // Replace streambuf so we can output Unicode to console
+  cmsys::ConsoleBuf::Manager consoleOut(std::cout);
+  cmsys::ConsoleBuf::Manager consoleErr(std::cerr, true);
+#endif
   cmsys::Encoding::CommandLineArguments args =
     cmsys::Encoding::CommandLineArguments::Main(ac, av);
   ac = args.argc();
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 5fce50f..a211425 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -123,6 +123,7 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
   SET(KWSYS_USE_FStream 1)
   SET(KWSYS_USE_String 1)
   SET(KWSYS_USE_SystemInformation 1)
+  SET(KWSYS_USE_ConsoleBuf 1)
 ENDIF()
 
 # Enforce component dependencies.
@@ -154,6 +155,9 @@ ENDIF()
 IF(KWSYS_USE_FStream)
   SET(KWSYS_USE_Encoding 1)
 ENDIF()
+IF(KWSYS_USE_ConsoleBuf)
+  SET(KWSYS_USE_Encoding 1)
+ENDIF()
 
 # Setup the large file support default.
 IF(KWSYS_LFS_DISABLE)
@@ -673,7 +677,7 @@ SET(KWSYS_HXX_FILES Configure String ProcessOutput
 # Add selected C++ classes.
 SET(cppclasses
   Directory DynamicLoader Encoding Glob RegularExpression SystemTools
-  CommandLineArguments IOStream FStream SystemInformation
+  CommandLineArguments IOStream FStream SystemInformation ConsoleBuf
   )
 FOREACH(cpp ${cppclasses})
   IF(KWSYS_USE_${cpp})
@@ -926,6 +930,17 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
         testFStream
         )
     ENDIF()
+    IF(KWSYS_USE_ConsoleBuf)
+      IF("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
+        add_compile_options(/utf-8)
+      ENDIF()
+      ADD_EXECUTABLE(testConsoleBufChild testConsoleBufChild.cxx)
+      SET_PROPERTY(TARGET testConsoleBufChild PROPERTY LABELS ${KWSYS_LABELS_EXE})
+      TARGET_LINK_LIBRARIES(testConsoleBufChild ${KWSYS_NAMESPACE})
+      SET(KWSYS_CXX_TESTS ${KWSYS_CXX_TESTS}
+        testConsoleBuf
+        )
+    ENDIF()
     IF(KWSYS_USE_SystemInformation)
       SET(KWSYS_CXX_TESTS ${KWSYS_CXX_TESTS} testSystemInformation)
     ENDIF()
diff --git a/Source/kwsys/ConsoleBuf.hxx.in b/Source/kwsys/ConsoleBuf.hxx.in
new file mode 100644
index 0000000..ed95bb0
--- /dev/null
+++ b/Source/kwsys/ConsoleBuf.hxx.in
@@ -0,0 +1,318 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+#define @KWSYS_NAMESPACE at _ConsoleBuf_hxx
+
+#include <@KWSYS_NAMESPACE@/Configure.hxx>
+#include <@KWSYS_NAMESPACE@/Encoding.hxx>
+#include <string>
+#include <cstring>
+#include <sstream>
+#include <streambuf>
+#include <iostream>
+#include <stdexcept>
+
+#if defined(_WIN32)
+#  include <windows.h>
+#  if __cplusplus >= 201103L
+#    include <system_error>
+#  endif
+#endif
+
+namespace @KWSYS_NAMESPACE@
+{
+#if defined(_WIN32)
+
+  template<class CharT, class Traits = std::char_traits<CharT> >
+  class @KWSYS_NAMESPACE at _EXPORT BasicConsoleBuf : public std::basic_streambuf<CharT, Traits> {
+    public:
+      typedef typename Traits::int_type int_type;
+      typedef typename Traits::char_type char_type;
+
+      class Manager {
+        public:
+          Manager(std::basic_ios<CharT, Traits> &ios, const bool err = false) : m_consolebuf(0)
+          {
+            m_ios = &ios;
+            try {
+              m_consolebuf = new BasicConsoleBuf<CharT, Traits>(err);
+              m_streambuf = m_ios->rdbuf(m_consolebuf);
+            } catch (const std::runtime_error& ex) {
+              std::cerr << "Failed to create ConsoleBuf!" << std::endl
+                        << ex.what() << std::endl;
+            };
+          }
+
+          ~Manager()
+          {
+            if (m_consolebuf) {
+              delete m_consolebuf;
+              m_ios->rdbuf(m_streambuf);
+            }
+          }
+
+        private:
+          std::basic_ios<CharT, Traits> *m_ios;
+          std::basic_streambuf<CharT, Traits> *m_streambuf;
+          BasicConsoleBuf<CharT, Traits> *m_consolebuf;
+      };
+
+      BasicConsoleBuf(const bool err = false) :
+        flush_on_newline(true),
+        input_pipe_codepage(0),
+        output_pipe_codepage(0),
+        input_file_codepage(CP_UTF8),
+        output_file_codepage(CP_UTF8),
+        m_consolesCodepage(0)
+      {
+        m_hInput = ::GetStdHandle(STD_INPUT_HANDLE);
+        checkHandle(true, "STD_INPUT_HANDLE");
+        setActiveCodepage(true, "STD_INPUT_HANDLE");
+        m_hOutput = err ? ::GetStdHandle(STD_ERROR_HANDLE) :
+                          ::GetStdHandle(STD_OUTPUT_HANDLE);
+        checkHandle(false, err ? "STD_ERROR_HANDLE" : "STD_OUTPUT_HANDLE");
+        setActiveCodepage(false, err ? "STD_ERROR_HANDLE" : "STD_OUTPUT_HANDLE");
+        _setg();
+        _setp();
+      }
+
+      ~BasicConsoleBuf()
+      {
+        sync();
+      }
+
+      void activateCodepageChange()
+      {
+        setActiveCodepage(true, "");
+        setActiveCodepage(false, "");
+      }
+
+    protected:
+      virtual int sync() {
+        bool success = true;
+        if (m_hInput && m_isConsoleInput && ::FlushConsoleInputBuffer(m_hInput) == 0) {
+          success = false;
+        }
+        if (m_hOutput && !m_obuffer.empty()) {
+          const std::wstring wbuffer = getBuffer(m_obuffer);
+          if (m_isConsoleOutput) {
+            DWORD charsWritten;
+            success = ::WriteConsoleW(m_hOutput, wbuffer.c_str(), (DWORD)wbuffer.size(), &charsWritten, NULL) == 0 ? false : true;
+          } else {
+            DWORD bytesWritten;
+            std::string buffer;
+            success = encodeOutputBuffer(wbuffer, buffer);
+            if (success) {
+              success = ::WriteFile(m_hOutput, buffer.c_str(), (DWORD)buffer.size(), &bytesWritten, NULL) == 0 ? false : true;
+            }
+          }
+        }
+        m_ibuffer.clear();
+        m_obuffer.clear();
+        _setg();
+        _setp();
+        return success ? 0 : -1;
+      }
+
+      virtual int_type underflow() {
+        if (this->gptr() >= this->egptr()) {
+          if (!m_hInput) {
+            _setg(true);
+            return Traits::eof();
+          }
+          if (m_isConsoleInput) {
+            wchar_t wbuffer[128];
+            DWORD charsRead;
+            if (::ReadConsoleW(m_hInput, wbuffer, ARRAYSIZE(wbuffer) - 1, &charsRead, NULL) == 0 || charsRead == 0) {
+              _setg(true);
+              return Traits::eof();
+            }
+            wbuffer[charsRead] = L'\0';
+            setBuffer(wbuffer, m_ibuffer);
+          } else {
+            std::wstring totalBuffer;
+            std::wstring wbuffer;
+            char buffer[128];
+            DWORD bytesRead;
+            while (::ReadFile(m_hInput, buffer, ARRAYSIZE(buffer) - 1, &bytesRead, NULL) == 0) {
+              if (::GetLastError() == ERROR_MORE_DATA) {
+                buffer[bytesRead] = '\0';
+                if (decodeInputBuffer(buffer, wbuffer)) {
+                  totalBuffer += wbuffer;
+                  continue;
+                }
+              }
+              _setg(true);
+              return Traits::eof();
+            }
+            buffer[bytesRead] = '\0';
+            if (!decodeInputBuffer(buffer, wbuffer)) {
+              _setg(true);
+              return Traits::eof();
+            }
+            totalBuffer += wbuffer;
+            setBuffer(totalBuffer, m_ibuffer);
+          }
+          _setg();
+        }
+        return Traits::to_int_type(*this->gptr());
+      }
+
+      virtual int_type overflow(int_type ch = Traits::eof()) {
+        if (!Traits::eq_int_type(ch, Traits::eof())) {
+          char_type chr = Traits::to_char_type(ch);
+          m_obuffer += chr;
+          if ((flush_on_newline && Traits::eq(chr, '\n')) || Traits::eq_int_type(ch, 0x00)) {
+            sync();
+          }
+          return ch;
+        }
+        sync();
+        return Traits::eof();
+      }
+
+    public:
+      bool flush_on_newline;
+      UINT input_pipe_codepage;
+      UINT output_pipe_codepage;
+      UINT input_file_codepage;
+      UINT output_file_codepage;
+
+    private:
+      HANDLE m_hInput;
+      HANDLE m_hOutput;
+      std::basic_string<char_type> m_ibuffer;
+      std::basic_string<char_type> m_obuffer;
+      bool m_isConsoleInput;
+      bool m_isConsoleOutput;
+      UINT m_activeInputCodepage;
+      UINT m_activeOutputCodepage;
+      UINT m_consolesCodepage;
+      void checkHandle(bool input, std::string handleName) {
+        if ((input && m_hInput == INVALID_HANDLE_VALUE) || (!input && m_hOutput == INVALID_HANDLE_VALUE)) {
+          std::string errmsg = "GetStdHandle(" + handleName + ") returned INVALID_HANDLE_VALUE";
+#if __cplusplus >= 201103L
+          throw std::system_error(::GetLastError(), std::system_category(), errmsg);
+#else
+          throw std::runtime_error(errmsg);
+#endif
+        }
+      }
+      UINT getConsolesCodepage() {
+        if (!m_consolesCodepage) {
+          m_consolesCodepage = GetConsoleCP();
+          if (!m_consolesCodepage) {
+            m_consolesCodepage = GetACP();
+          }
+        }
+        return m_consolesCodepage;
+      }
+      void setActiveCodepage(bool input, std::string handleName) {
+        std::ostringstream errmsg;
+        DWORD ft;
+        switch (ft = GetFileType(input ? m_hInput : m_hOutput)) {
+          case FILE_TYPE_DISK:
+            if (input) {
+               m_isConsoleInput = false;
+               m_activeInputCodepage = input_file_codepage;
+            } else {
+               m_isConsoleOutput = false;
+               m_activeOutputCodepage = output_file_codepage;
+            };
+            break;
+          case FILE_TYPE_CHAR:
+            if (input) {
+              m_isConsoleInput = true;
+            } else {
+              m_isConsoleOutput = true;
+            };
+            break;
+          case FILE_TYPE_PIPE:
+            if (input) {
+              m_isConsoleInput = false;
+              m_activeInputCodepage = input_pipe_codepage;
+            } else {
+              m_isConsoleOutput = false;
+              m_activeOutputCodepage = output_pipe_codepage;
+            };
+            break;
+          default:
+            errmsg << "GetFileType for " << handleName << " returned unknown file type " << ft;
+#if __cplusplus >= 201103L
+            throw std::system_error(::GetLastError(), std::system_category(), errmsg.str());
+#else
+            throw std::runtime_error(errmsg.str());
+#endif
+        }
+        if (input && !m_isConsoleInput && m_activeInputCodepage == 0) {
+           m_activeInputCodepage = getConsolesCodepage();
+        } else if (!input && !m_isConsoleOutput && m_activeOutputCodepage == 0) {
+           m_activeOutputCodepage = getConsolesCodepage();
+        }
+      }
+      void _setg(bool empty = false) {
+        if (!empty) {
+          this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        } else {
+          this->setg((char_type *)m_ibuffer.data(), (char_type *)m_ibuffer.data() + m_ibuffer.size(), (char_type *)m_ibuffer.data() + m_ibuffer.size());
+        }
+      }
+      void _setp() {
+        this->setp((char_type *)m_obuffer.data(), (char_type *)m_obuffer.data() + m_obuffer.size());
+      }
+      bool encodeOutputBuffer(const std::wstring wbuffer, std::string &buffer) {
+        const int length = WideCharToMultiByte(m_activeOutputCodepage, 0, wbuffer.c_str(), (int)wbuffer.size(), NULL, 0, NULL, NULL);
+        char *buf = new char[length + 1];
+        const bool success = WideCharToMultiByte(m_activeOutputCodepage, 0, wbuffer.c_str(), (int)wbuffer.size(), buf, length, NULL, NULL) > 0 ? true : false;
+        buf[length] = '\0';
+        buffer = buf;
+        delete[] buf;
+        return success;
+      }
+      bool decodeInputBuffer(const char *buffer, std::wstring &wbuffer) {
+        int actualCodepage = m_activeInputCodepage;
+        const char BOM_UTF8[] = { char(0xEF), char(0xBB), char(0xBF) };
+        if (std::memcmp(buffer, BOM_UTF8, sizeof(BOM_UTF8)) == 0) {
+          // PowerShell uses UTF-8 with BOM for pipes
+          actualCodepage = CP_UTF8;
+          buffer += sizeof(BOM_UTF8);
+        }
+        const int wlength = MultiByteToWideChar(actualCodepage, 0, buffer, -1, NULL, 0);
+        wchar_t *wbuf = new wchar_t[wlength];
+        const bool success = MultiByteToWideChar(actualCodepage, 0, buffer, -1, wbuf, wlength) > 0 ? true : false;
+        wbuffer = wbuf;
+        delete[] wbuf;
+        return success;
+      }
+      std::wstring getBuffer(const std::basic_string<char> buffer) {
+        return Encoding::ToWide(buffer);
+      }
+      std::wstring getBuffer(const std::basic_string<wchar_t> buffer) {
+        return buffer;
+      }
+      void setBuffer(const std::wstring wbuffer, std::basic_string<char> &target) {
+        target = Encoding::ToNarrow(wbuffer);
+      }
+      void setBuffer(const std::wstring wbuffer, std::basic_string<wchar_t> &target) {
+        target = wbuffer;
+      }
+
+  }; // BasicConsoleBuf class
+
+  typedef BasicConsoleBuf<char>    ConsoleBuf;
+  typedef BasicConsoleBuf<wchar_t> WConsoleBuf;
+
+#endif
+} // KWSYS_NAMESPACE
+
+#endif
+
diff --git a/Source/kwsys/testConsoleBuf.cxx b/Source/kwsys/testConsoleBuf.cxx
new file mode 100644
index 0000000..3dc395a
--- /dev/null
+++ b/Source/kwsys/testConsoleBuf.cxx
@@ -0,0 +1,424 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#include "kwsysPrivate.h"
+
+#include KWSYS_HEADER(Encoding.hxx)
+
+// Work-around CMake dependency scanning limitation.  This must
+// duplicate the above list of headers.
+#if 0
+# include "Encoding.hxx.in"
+#endif
+
+#if defined(_WIN32)
+
+#include <windows.h>
+#include <iostream>
+#include <locale>
+#include <codecvt>
+#include "testConsoleBuf.hxx"
+
+// ???????
+static const WCHAR UnicodeInputTestString[] = L"\u064A\u0648\u0646\u064A\u0643\u0648\u062F!";
+static const UINT TestCodepage = 1251; // ANSI Cyrillic
+
+static const DWORD waitTimeout = 10 * 1000;
+static STARTUPINFO startupInfo;
+static PROCESS_INFORMATION processInfo;
+static HANDLE syncEvent;
+
+//----------------------------------------------------------------------------
+static bool createProcess(HANDLE hIn, HANDLE hOut, HANDLE hErr)
+{
+  BOOL bInheritHandles = FALSE;
+  DWORD dwCreationFlags = 0;
+  SecureZeroMemory(&processInfo, sizeof(processInfo));
+  SecureZeroMemory(&startupInfo, sizeof(startupInfo));
+  startupInfo.cb = sizeof(startupInfo);
+  startupInfo.dwFlags = STARTF_USESHOWWINDOW;
+  startupInfo.wShowWindow = SW_HIDE;
+  if (hIn || hOut || hErr) {
+    startupInfo.dwFlags |= STARTF_USESTDHANDLES;
+    startupInfo.hStdInput = hIn;
+    startupInfo.hStdOutput = hOut;
+    startupInfo.hStdError = hErr;
+    bInheritHandles = TRUE;
+  }
+
+  WCHAR cmd[MAX_PATH];
+  if (GetModuleFileNameW(NULL, cmd, MAX_PATH) == 0) {
+    std::cerr << "GetModuleFileName failed!" << std::endl;
+    return false;
+  }
+  WCHAR *p = cmd + wcslen(cmd);
+  while (p > cmd && *p != L'\\') p--;
+  *(p+1) = 0;
+  wcscat_s(cmd, MAX_PATH, cmdConsoleBufChild);
+
+  bool success = CreateProcessW(NULL,             // No module name (use command line)
+                                cmd,              // Command line
+                                NULL,             // Process handle not inheritable
+                                NULL,             // Thread handle not inheritable
+                                bInheritHandles,  // Set handle inheritance
+                                dwCreationFlags,
+                                NULL,             // Use parent's environment block
+                                NULL,             // Use parent's starting directory
+                                &startupInfo,     // Pointer to STARTUPINFO structure
+                                &processInfo) != 0; // Pointer to PROCESS_INFORMATION structure
+  if (!success) {
+      std::cerr << "CreateProcess(" << kwsys::Encoding::ToNarrow(cmd) << ") failed!" << std::endl;
+  }
+  return success;
+}
+
+//----------------------------------------------------------------------------
+static void finishProcess(bool success)
+{
+  if (success) {
+    success = WaitForSingleObject(processInfo.hProcess, waitTimeout) == WAIT_OBJECT_0;
+  };
+  if (!success) {
+    TerminateProcess(processInfo.hProcess, 1);
+  }
+  CloseHandle(processInfo.hProcess);
+  CloseHandle(processInfo.hThread);
+}
+
+//----------------------------------------------------------------------------
+static bool createPipe(PHANDLE readPipe, PHANDLE writePipe)
+{
+  SECURITY_ATTRIBUTES securityAttributes;
+  securityAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
+  securityAttributes.bInheritHandle = TRUE;
+  securityAttributes.lpSecurityDescriptor = NULL;
+  return CreatePipe(readPipe, writePipe, &securityAttributes, 0) == 0 ? false : true;
+}
+
+//----------------------------------------------------------------------------
+static void finishPipe(HANDLE readPipe, HANDLE writePipe)
+{
+  if (readPipe != INVALID_HANDLE_VALUE) {
+    CloseHandle(readPipe);
+  }
+  if (writePipe != INVALID_HANDLE_VALUE) {
+    CloseHandle(writePipe);
+  }
+}
+
+//----------------------------------------------------------------------------
+static HANDLE createFile(LPCWSTR fileName)
+{
+  SECURITY_ATTRIBUTES securityAttributes;
+  securityAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
+  securityAttributes.bInheritHandle = TRUE;
+  securityAttributes.lpSecurityDescriptor = NULL;
+
+  HANDLE file = CreateFileW(fileName,
+                            GENERIC_READ | GENERIC_WRITE,
+                            0,                    // do not share
+                            &securityAttributes,
+                            CREATE_ALWAYS,        // overwrite existing
+                            FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE,
+                            NULL);                // no template
+  if (file == INVALID_HANDLE_VALUE) {
+    std::cerr << "CreateFile(" << kwsys::Encoding::ToNarrow(fileName) << ") failed!" << std::endl;
+  }
+  return file;
+}
+
+//----------------------------------------------------------------------------
+static void finishFile(HANDLE file)
+{
+  if (file != INVALID_HANDLE_VALUE) {
+    CloseHandle(file);
+  }
+}
+
+//----------------------------------------------------------------------------
+static void writeInputKeyEvent(INPUT_RECORD inputBuffer[], WCHAR chr)
+{
+  inputBuffer[0].EventType = KEY_EVENT;
+  inputBuffer[0].Event.KeyEvent.bKeyDown = TRUE;
+  inputBuffer[0].Event.KeyEvent.wRepeatCount = 1;
+  SHORT keyCode = VkKeyScanW(chr);
+  if (keyCode == -1) {
+    // Character can't be entered with current keyboard layout
+    // Just set any, it doesn't really matter
+    keyCode = 'K';
+  }
+  inputBuffer[0].Event.KeyEvent.wVirtualKeyCode = LOBYTE(keyCode);
+  inputBuffer[0].Event.KeyEvent.wVirtualScanCode = MapVirtualKey(inputBuffer[0].Event.KeyEvent.wVirtualKeyCode, MAPVK_VK_TO_VSC);
+  inputBuffer[0].Event.KeyEvent.uChar.UnicodeChar = chr;
+  inputBuffer[0].Event.KeyEvent.dwControlKeyState = 0;
+  if ((HIBYTE(keyCode) & 1) == 1) {
+    inputBuffer[0].Event.KeyEvent.dwControlKeyState |= SHIFT_PRESSED;
+  }
+  if ((HIBYTE(keyCode) & 2) == 2) {
+    inputBuffer[0].Event.KeyEvent.dwControlKeyState |= RIGHT_CTRL_PRESSED;
+  }
+  if ((HIBYTE(keyCode) & 4) == 4) {
+    inputBuffer[0].Event.KeyEvent.dwControlKeyState |= RIGHT_ALT_PRESSED;
+  }
+  inputBuffer[1].EventType = inputBuffer[0].EventType;
+  inputBuffer[1].Event.KeyEvent.bKeyDown = FALSE;
+  inputBuffer[1].Event.KeyEvent.wRepeatCount = 1;
+  inputBuffer[1].Event.KeyEvent.wVirtualKeyCode = inputBuffer[0].Event.KeyEvent.wVirtualKeyCode;
+  inputBuffer[1].Event.KeyEvent.wVirtualScanCode = inputBuffer[0].Event.KeyEvent.wVirtualScanCode;
+  inputBuffer[1].Event.KeyEvent.uChar.UnicodeChar = inputBuffer[0].Event.KeyEvent.uChar.UnicodeChar;
+  inputBuffer[1].Event.KeyEvent.dwControlKeyState = 0;
+}
+
+//----------------------------------------------------------------------------
+static int testPipe()
+{
+  int didFail = 1;
+  HANDLE inPipeRead = INVALID_HANDLE_VALUE;
+  HANDLE inPipeWrite = INVALID_HANDLE_VALUE;
+  HANDLE outPipeRead = INVALID_HANDLE_VALUE;
+  HANDLE outPipeWrite = INVALID_HANDLE_VALUE;
+  HANDLE errPipeRead = INVALID_HANDLE_VALUE;
+  HANDLE errPipeWrite = INVALID_HANDLE_VALUE;
+  UINT currentCodepage = GetConsoleCP();
+  char buffer[200];
+  std::string encodedInputTestString;
+  std::string encodedTestString;
+  try {
+    if (!createPipe(&inPipeRead, &inPipeWrite) ||
+        !createPipe(&outPipeRead, &outPipeWrite) ||
+        !createPipe(&errPipeRead, &errPipeWrite)) {
+      throw std::runtime_error("createFile failed!");
+    }
+    if (!SetConsoleCP(TestCodepage)) {
+      throw std::runtime_error("SetConsoleCP failed!");
+    }
+
+    if (WideCharToMultiByte(TestCodepage, 0, UnicodeTestString, -1, buffer, sizeof(buffer), NULL, NULL) == 0) {
+      throw std::runtime_error("WideCharToMultiByte failed!");
+    }
+    encodedTestString = buffer;
+
+    if (WideCharToMultiByte(TestCodepage, 0, UnicodeInputTestString, -1, buffer, sizeof(buffer), NULL, NULL) == 0) {
+      throw std::runtime_error("WideCharToMultiByte failed!");
+    }
+    encodedInputTestString = buffer;
+    encodedInputTestString += "\n";
+
+    DWORD bytesWritten = 0;
+    if (!WriteFile(inPipeWrite, encodedInputTestString.c_str(), (DWORD)encodedInputTestString.size(), &bytesWritten, NULL) || bytesWritten == 0) {
+      throw std::runtime_error("WriteFile failed!");
+    }
+
+    if (createProcess(inPipeRead, outPipeWrite, errPipeWrite)) {
+      try {
+        Sleep(100);
+        if (WaitForSingleObject(syncEvent, waitTimeout) != WAIT_OBJECT_0) {
+          throw std::runtime_error("WaitForSingleObject failed!");
+        }
+        DWORD bytesRead = 0;
+        if (!ReadFile(outPipeRead, buffer, sizeof(buffer), &bytesRead, NULL) || bytesRead == 0) {
+          throw std::runtime_error("ReadFile failed!");
+        }
+        if (memcmp(buffer, encodedTestString.c_str(), encodedTestString.size()) == 0 &&
+            memcmp(buffer + encodedTestString.size() + 1, encodedInputTestString.c_str(), encodedInputTestString.size()) == 0) {
+          bytesRead = 0;
+          if (!ReadFile(errPipeRead, buffer, sizeof(buffer), &bytesRead, NULL) || bytesRead == 0) {
+            throw std::runtime_error("ReadFile failed!");
+          }
+          buffer[bytesRead - 1] = 0;
+          didFail = encodedTestString.compare(buffer) == 0 ? 0 : 1;
+        }
+      } catch (const std::runtime_error &ex) {
+        std::cerr << ex.what() << std::endl << std::flush;
+      }
+      finishProcess(didFail == 0);
+    }
+  } catch (const std::runtime_error &ex) {
+    std::cerr << ex.what() << std::endl << std::flush;
+  }
+  finishPipe(inPipeRead, inPipeWrite);
+  finishPipe(outPipeRead, outPipeWrite);
+  finishPipe(errPipeRead, errPipeWrite);
+  SetConsoleCP(currentCodepage);
+  return didFail;
+}
+
+//----------------------------------------------------------------------------
+static int testFile()
+{
+  int didFail = 1;
+  HANDLE inFile = INVALID_HANDLE_VALUE;
+  HANDLE outFile = INVALID_HANDLE_VALUE;
+  HANDLE errFile = INVALID_HANDLE_VALUE;
+  try {
+    if ((inFile = createFile(L"stdinFile.txt")) == INVALID_HANDLE_VALUE ||
+        (outFile = createFile(L"stdoutFile.txt")) == INVALID_HANDLE_VALUE ||
+        (errFile = createFile(L"stderrFile.txt")) == INVALID_HANDLE_VALUE) {
+      throw std::runtime_error("createFile failed!");
+    }
+    int length = 0;
+    DWORD bytesWritten = 0;
+    char buffer[200];
+
+    if ((length = WideCharToMultiByte(CP_UTF8, 0, UnicodeInputTestString, -1, buffer, sizeof(buffer), NULL, NULL)) == 0) {
+      throw std::runtime_error("WideCharToMultiByte failed!");
+    }
+    buffer[length - 1] = '\n';
+    if (!WriteFile(inFile, buffer, length, &bytesWritten, NULL) || bytesWritten == 0) {
+      throw std::runtime_error("WriteFile failed!");
+    }
+    if (SetFilePointer(inFile, 0, 0, FILE_BEGIN) == INVALID_SET_FILE_POINTER) {
+      throw std::runtime_error("SetFilePointer failed!");
+    }
+
+    if (createProcess(inFile, outFile, errFile)) {
+      DWORD bytesRead = 0;
+      WCHAR wbuffer[200];
+      std::wstring wstr;
+      try {
+        Sleep(100);
+        if (WaitForSingleObject(syncEvent, waitTimeout) != WAIT_OBJECT_0) {
+          throw std::runtime_error("WaitForSingleObject failed!");
+        }
+        if (SetFilePointer(outFile, 0, 0, FILE_BEGIN) == INVALID_SET_FILE_POINTER) {
+          throw std::runtime_error("SetFilePointer failed!");
+        }
+        if (!ReadFile(outFile, buffer, sizeof(buffer), &bytesRead, NULL) || bytesRead == 0) {
+          throw std::runtime_error("ReadFile failed!");
+        }
+        buffer[bytesRead - 1] = 0;
+        if (MultiByteToWideChar(CP_UTF8, 0, buffer, -1, wbuffer, sizeof(wbuffer)) == 0) {
+          throw std::runtime_error("MultiByteToWideChar failed!");
+        }
+        wstr = wbuffer;
+        if (wstr.compare(std::wstring(UnicodeTestString) + L"\n" + UnicodeInputTestString) == 0) {
+          bytesRead = 0;
+          if (SetFilePointer(errFile, 0, 0, FILE_BEGIN) == INVALID_SET_FILE_POINTER) {
+            throw std::runtime_error("SetFilePointer failed!");
+          }
+          if (!ReadFile(errFile, buffer, sizeof(buffer), &bytesRead, NULL) || bytesRead == 0) {
+            throw std::runtime_error("ReadFile failed!");
+          }
+          buffer[bytesRead - 1] = 0;
+          if (MultiByteToWideChar(CP_UTF8, 0, buffer, -1, wbuffer, sizeof(wbuffer)) == 0) {
+            throw std::runtime_error("MultiByteToWideChar failed!");
+          }
+          wstr = wbuffer;
+          didFail = wstr.compare(UnicodeTestString) == 0 ? 0 : 1;
+        }
+      } catch (const std::runtime_error &ex) {
+        std::cerr << ex.what() << std::endl << std::flush;
+      }
+      finishProcess(didFail == 0);
+    }
+  } catch (const std::runtime_error &ex) {
+    std::cerr << ex.what() << std::endl << std::flush;
+  }
+  finishFile(inFile);
+  finishFile(outFile);
+  finishFile(errFile);
+  return didFail;
+}
+
+//----------------------------------------------------------------------------
+static int testConsole()
+{
+  int didFail = 1;
+  if (createProcess(NULL, NULL, NULL)) {
+    try {
+      if (WaitForSingleObject(syncEvent, waitTimeout) != WAIT_OBJECT_0) {
+        throw std::runtime_error("WaitForSingleObject failed!");
+      }
+      HANDLE hIn = GetStdHandle(STD_INPUT_HANDLE);
+      HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
+      if (hIn  == INVALID_HANDLE_VALUE || hIn == NULL ||
+          hOut == INVALID_HANDLE_VALUE || hOut == NULL) {
+        throw std::runtime_error("GetStdHandle failed!");
+      }
+      if (GetFileType(hOut) != FILE_TYPE_CHAR) {
+        // Not a console so we can't test this, just skip
+        // we might be running under MSYS2 (mintty)
+        didFail = 0;
+        TerminateProcess(processInfo.hProcess, 0);
+        throw std::runtime_error("Not a Console, skipping this test!");
+      }
+
+      INPUT_RECORD inputBuffer[(sizeof(UnicodeInputTestString) / sizeof(UnicodeInputTestString[0])) * 2];
+      SecureZeroMemory(&inputBuffer, sizeof(inputBuffer));
+      unsigned int i = 0;
+      for (i = 0; i < (sizeof(UnicodeInputTestString) / sizeof(UnicodeInputTestString[0]) - 1); i++) {
+        writeInputKeyEvent(&inputBuffer[i*2], UnicodeInputTestString[i]);
+      }
+      writeInputKeyEvent(&inputBuffer[i*2], VK_RETURN);
+      DWORD eventsWritten = 0;
+      if (!WriteConsoleInputW(hIn, inputBuffer, sizeof(inputBuffer) / sizeof(inputBuffer[0]), &eventsWritten) || eventsWritten == 0) {
+        throw std::runtime_error("WriteConsoleInput failed!");
+      }
+      if (WaitForSingleObject(syncEvent, waitTimeout) != WAIT_OBJECT_0) {
+        throw std::runtime_error("WaitForSingleObject failed!");
+      }
+      CONSOLE_SCREEN_BUFFER_INFO screenBufferInfo;
+      if (!GetConsoleScreenBufferInfo(hOut, &screenBufferInfo)) {
+        throw std::runtime_error("GetConsoleScreenBufferInfo failed!");
+      }
+
+      COORD coord;
+      DWORD charsRead = 0;
+      coord.X = 0;
+      coord.Y = screenBufferInfo.dwCursorPosition.Y - 4;
+      WCHAR *outputBuffer = new WCHAR[screenBufferInfo.dwSize.X * 4];
+      if (!ReadConsoleOutputCharacterW(hOut, outputBuffer, screenBufferInfo.dwSize.X * 4, coord, &charsRead) || charsRead == 0) {
+        delete[] outputBuffer;
+        throw std::runtime_error("ReadConsoleOutputCharacter failed!");
+      }
+      if (memcmp(outputBuffer, UnicodeTestString, sizeof(UnicodeTestString) - sizeof(WCHAR)) == 0 &&
+          memcmp(outputBuffer + screenBufferInfo.dwSize.X * 1, UnicodeTestString, sizeof(UnicodeTestString) - sizeof(WCHAR)) == 0 &&
+          memcmp(outputBuffer + screenBufferInfo.dwSize.X * 2, UnicodeInputTestString, sizeof(UnicodeInputTestString) - sizeof(WCHAR)) == 0 &&
+          memcmp(outputBuffer + screenBufferInfo.dwSize.X * 3, UnicodeInputTestString, sizeof(UnicodeInputTestString) - sizeof(WCHAR)) == 0
+      ) {
+        didFail = 0;
+      }
+      delete[] outputBuffer;
+    } catch (const std::runtime_error &ex) {
+      std::cerr << ex.what() << std::endl << std::flush;
+    }
+    finishProcess(didFail == 0);
+  }
+  return didFail;
+}
+
+#endif
+
+//----------------------------------------------------------------------------
+int testConsoleBuf(int, char*[])
+{
+  int ret = 0;
+
+#if defined(_WIN32)
+  syncEvent = CreateEventW(NULL,
+                           FALSE,  // auto-reset event
+                           FALSE,  // initial state is nonsignaled
+                           SyncEventName);  // object name
+  if (!syncEvent) {
+    std::cerr << "CreateEvent failed " << GetLastError() << std::endl;
+    return 1;
+  }
+
+  ret |= testPipe();
+  ret |= testFile();
+  ret |= testConsole();
+
+  CloseHandle(syncEvent);
+#endif
+
+  return ret;
+}
+
diff --git a/Source/kwsys/testConsoleBuf.hxx b/Source/kwsys/testConsoleBuf.hxx
new file mode 100644
index 0000000..6736be6
--- /dev/null
+++ b/Source/kwsys/testConsoleBuf.hxx
@@ -0,0 +1,25 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#ifndef testConsoleBuf_hxx
+#define testConsoleBuf_hxx
+
+static const wchar_t cmdConsoleBufChild[] = L"testConsoleBufChild";
+
+static const wchar_t SyncEventName[] = L"SyncEvent";
+
+// ??????? ????? ???????!
+static const wchar_t UnicodeTestString[] = L"\u092F\u0942\u0928\u093F\u0915\u094B\u0921 "
+                                           L"\u03B5\u03AF\u03BD\u03B1\u03B9 "
+                                           L"\u0437\u0434\u043E\u0440\u043E\u0432\u043E!";
+
+#endif
+
diff --git a/Source/kwsys/testConsoleBufChild.cxx b/Source/kwsys/testConsoleBufChild.cxx
new file mode 100644
index 0000000..8608b72
--- /dev/null
+++ b/Source/kwsys/testConsoleBufChild.cxx
@@ -0,0 +1,59 @@
+/*============================================================================
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+============================================================================*/
+#include "kwsysPrivate.h"
+
+#include KWSYS_HEADER(ConsoleBuf.hxx)
+#include KWSYS_HEADER(Encoding.hxx)
+
+// Work-around CMake dependency scanning limitation.  This must
+// duplicate the above list of headers.
+#if 0
+# include "ConsoleBuf.hxx.in"
+# include "Encoding.hxx.in"
+#endif
+
+#include <iostream>
+#include "testConsoleBuf.hxx"
+
+//----------------------------------------------------------------------------
+int main(int argc, const char* argv[])
+{
+#if defined(_WIN32)
+  kwsys::ConsoleBuf::Manager out(std::cout);
+  kwsys::ConsoleBuf::Manager err(std::cerr, true);
+  kwsys::ConsoleBuf::Manager in(std::cin);
+
+  if (argc > 1) {
+    std::cout << argv[1] << std::endl;
+    std::cerr << argv[1] << std::endl;
+  } else {
+    std::string str = kwsys::Encoding::ToNarrow(UnicodeTestString);
+    std::cout << str << std::endl;
+    std::cerr << str << std::endl;
+  }
+
+  std::string input;
+  HANDLE syncEvent = OpenEventW(EVENT_MODIFY_STATE, FALSE, SyncEventName);
+  if (syncEvent) {
+    SetEvent(syncEvent);
+  }
+
+  std::cin >> input;
+  std::cout << input << std::endl;
+  if (syncEvent) {
+    SetEvent(syncEvent);
+    CloseHandle(syncEvent);
+  }
+#endif
+  return 0;
+}
+
diff --git a/bootstrap b/bootstrap
index aa7307d..5fe4e0e 100755
--- a/bootstrap
+++ b/bootstrap
@@ -365,6 +365,7 @@ KWSYS_CXX_SOURCES="\
   SystemTools"
 
 KWSYS_FILES="\
+  ConsoleBuf.hxx \
   Directory.hxx \
   Encoding.h \
   Encoding.hxx \
-- 
2.9.0


From ben.boeckel at kitware.com  Wed Jul 27 13:31:06 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 27 Jul 2016 13:31:06 -0400
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
 <20160727151157.GA30225@megas.kitware.com>
 <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>
Message-ID: <20160727173106.GA24751@rotor.kitware.com>

On Wed, Jul 27, 2016 at 17:49:40 +0200, Sebastian Holtermann wrote:
> Is there an error exit function in CMake?
> Or just exit(-1);

Here's an example I found:

    this->Makefile->IssueMessage(
      cmake::INTERNAL_ERROR, "fileFound is true but FileFound is empty!");

after that, it is treated as if an error occurred; this loop should
probably be bailed from.

--Ben

From seblist at xwmw.org  Wed Jul 27 14:07:37 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Wed, 27 Jul 2016 20:07:37 +0200
Subject: [cmake-developers] Autogen subdirectories patches
In-Reply-To: <20160727173106.GA24751@rotor.kitware.com>
References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com>
 <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com>
 <0127b83a-fbfd-3696-2bc0-0a7f00cae0d9@kitware.com>
 <bdb645cd-1ab0-db9b-b92b-98112a095b11@xwmw.org>
 <20160726155316.GD14126@rotor>
 <83965c38-5421-faf2-109c-a339ddf6ace2@xwmw.org>
 <20160727151157.GA30225@megas.kitware.com>
 <35645d35-26d7-6ea3-cd73-16e797cebbae@xwmw.org>
 <20160727173106.GA24751@rotor.kitware.com>
Message-ID: <834ec2fe-796b-787e-d698-22e1f6fc5383@xwmw.org>

Am 27.07.2016 um 19:31 schrieb Ben Boeckel:
> On Wed, Jul 27, 2016 at 17:49:40 +0200, Sebastian Holtermann wrote:
>> Is there an error exit function in CMake?
>> Or just exit(-1);
>
> Here's an example I found:
>
>     this->Makefile->IssueMessage(
>       cmake::INTERNAL_ERROR, "fileFound is true but FileFound is empty!");
>
> after that, it is treated as if an error occurred; this loop should
> probably be bailed from.

Unfortunately the function is called in two places of which one
does not provide a Makefile (the cmake -E call).

It is very unlikely that an invalid character appears ever
and if it does it is likely that something else is very wrong.
In the patch I sent earlier in this case cmake just drops a note
via std::cerr and calls exit(-1). IMO this is sufficient.

-Sebastian



From sergey.nikulov at gmail.com  Thu Jul 28 06:33:35 2016
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Thu, 28 Jul 2016 13:33:35 +0300
Subject: [cmake-developers] Strange behaviour with check_library_exists on
	Windows
Message-ID: <CAE7Ac0Ac4+EGtAuBcEjfArAWHpToy+Qtb5L9_T5rVGd+6P9WVw@mail.gmail.com>

Hello,

While verifying curl library build issue on Windows - I've discovered
some differences in check_library_exists behaviour for different
targets 64 vs 32 bits.

The problem as follows - check_library_exists find library symbol when
Win64 platform used, but not for default 32 bit.

Here the output for Win64 bit generation
-----------------------------------------
E:\WORK\github\cmake_issue_checklibraryexist\build.64>cmake ..
-G"Visual Studio 14 2015 Win64"
-- The C compiler identification is MSVC 19.0.24210.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft
Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft
Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Looking for CertFreeCertificateContext in crypt32;
-- Looking for CertFreeCertificateContext in crypt32; - found
crypt32 found
-- Configuring done
-- Generating done
-- Build files have been written to:
E:/WORK/github/cmake_issue_checklibraryexist/build.64
-----------------------------------------

Here the output for 32-bit generation
-----------------------------------------
E:\WORK\github\cmake_issue_checklibraryexist\build.32>cmake ..
-G"Visual Studio 14 2015"
-- The C compiler identification is MSVC 19.0.24210.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft
Visual Studio 14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft
Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Looking for CertFreeCertificateContext in crypt32;
-- Looking for CertFreeCertificateContext in crypt32; - not found
crypt32 not found
-- Configuring done
-- Generating done
-- Build files have been written to:
E:/WORK/github/cmake_issue_checklibraryexist/build.32
-----------------------------------------

I've provided MVE on GitHub
https://github.com/snikulov/cmake_issue_checklibraryexist


Is this expected behavior our known issue?

CMake version is 3.6.0

Thank you.

-- 
Best Regards,
Sergei Nikulov

From ben.boeckel at kitware.com  Thu Jul 28 08:03:04 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 28 Jul 2016 08:03:04 -0400
Subject: [cmake-developers] Strange behaviour with check_library_exists
 on Windows
In-Reply-To: <CAE7Ac0Ac4+EGtAuBcEjfArAWHpToy+Qtb5L9_T5rVGd+6P9WVw@mail.gmail.com>
References: <CAE7Ac0Ac4+EGtAuBcEjfArAWHpToy+Qtb5L9_T5rVGd+6P9WVw@mail.gmail.com>
Message-ID: <20160728120304.GA17760@megas.kitware.com>

On Thu, Jul 28, 2016 at 13:33:35 +0300, Sergei Nikulov wrote:
> -- Looking for CertFreeCertificateContext in crypt32;
> -- Looking for CertFreeCertificateContext in crypt32; - found
> crypt32 found

These are tested using try_compile. Is there anything interesting under
CMakeFiles/CMakeTmp/* when you configure with --debug-trycompile? It
should contain the example files used and output from the compiler.

Thanks,

--Ben

From sergey.nikulov at gmail.com  Thu Jul 28 09:58:43 2016
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Thu, 28 Jul 2016 16:58:43 +0300
Subject: [cmake-developers] Strange behaviour with check_library_exists
	on Windows
In-Reply-To: <20160728120304.GA17760@megas.kitware.com>
References: <CAE7Ac0Ac4+EGtAuBcEjfArAWHpToy+Qtb5L9_T5rVGd+6P9WVw@mail.gmail.com>
 <20160728120304.GA17760@megas.kitware.com>
Message-ID: <CAE7Ac0Cwi9zuX0L7sCJu-yEyh9d4GLV6yyauaX4eyUXXZCT5yw@mail.gmail.com>

2016-07-28 15:03 GMT+03:00 Ben Boeckel <ben.boeckel at kitware.com>:
> On Thu, Jul 28, 2016 at 13:33:35 +0300, Sergei Nikulov wrote:
>> -- Looking for CertFreeCertificateContext in crypt32;
>> -- Looking for CertFreeCertificateContext in crypt32; - found
>> crypt32 found
>
> These are tested using try_compile. Is there anything interesting under
> CMakeFiles/CMakeTmp/* when you configure with --debug-trycompile? It
> should contain the example files used and output from the compiler.
>

Ben,

Could you please provide me with information what should be
interesting for me exactly?

Here is my investigate

32-bit build

CL.command.1.tlog
-------------------------------------------------------------
^C:\PROGRAM FILES\CMAKE\SHARE\CMAKE-3.6\MODULES\CHECKFUNCTIONEXISTS.C
/c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D
CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG /D
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"CMTC_67614.DIR\DEBUG\\"
/Fd"CMTC_67614.DIR\DEBUG\VC140.PDB" /Gd /TC /analyze- C:\PROGRAM
FILES\CMAKE\SHARE\CMAKE-3.6\MODULES\CHECKFUNCTIONEXISTS.C
-------------------------------------------------------------
link.command.1.tlog  is empty

Dumpbin output
-------------------------------------------------------------
E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\cmTC_6
7614.dir\Debug>dumpbin /SYMBOLS CheckFunctionExists.obj
Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file CheckFunctionExists.obj

File Type: COFF OBJECT

COFF SYMBOL TABLE
000 01045E92 ABS    notype       Static       | @comp.id
001 80000191 ABS    notype       Static       | @feat.00
002 00000000 SECT1  notype       Static       | .drectve
    Section length   30, #relocs    0, #linenums    0, checksum        0
004 00000000 SECT2  notype       Static       | .debug$S
    Section length  270, #relocs    5, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .debug$T
    Section length   88, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT4  notype       Static       | .text$mn
    Section length   2F, #relocs    2, #linenums    0, checksum ED2BC9DE
00A 00000000 UNDEF  notype ()    External     | _CertFreeCertificateContext
00B 00000000 SECT4  notype ()    External     | _main
00C 00000000 UNDEF  notype ()    External     | __RTC_CheckEsp
00D 00000000 UNDEF  notype ()    External     | __RTC_InitBase
00E 00000000 UNDEF  notype ()    External     | __RTC_Shutdown
00F 00000000 SECT5  notype       Static       | .rtc$IMZ
    Section length    4, #relocs    1, #linenums    0, checksum        0, select
ion    2 (pick any)
011 00000000 SECT5  notype       Static       | __RTC_InitBase.rtc$IMZ
012 00000000 SECT6  notype       Static       | .rtc$TMZ
    Section length    4, #relocs    1, #linenums    0, checksum        0, select
ion    2 (pick any)
014 00000000 SECT6  notype       Static       | __RTC_Shutdown.rtc$TMZ

String Table Size = 0x7B bytes

  Summary

         270 .debug$S
          88 .debug$T
          30 .drectve
           4 .rtc$IMZ
           4 .rtc$TMZ
          2F .text$mn

E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\cmTC_6
7614.dir\Debug>

64-bit build

CL.command.1.tlog
-------------------------------------------------------------
^C:\PROGRAM FILES\CMAKE\SHARE\CMAKE-3.6\MODULES\CHECKFUNCTIONEXISTS.C
/c /Zi /W3 /WX- /Od /Ob0 /D WIN32 /D _WINDOWS /D
CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG /D
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"CMTC_7909E.DIR\DEBUG\\"
/Fd"CMTC_7909E.DIR\DEBUG\VC140.PDB" /Gd /TC C:\PROGRAM
FILES\CMAKE\SHARE\CMAKE-3.6\MODULES\CHECKFUNCTIONEXISTS.C
-------------------------------------------------------------

link.command.1.tlog
-------------------------------------------------------------
^E:\WORK\GITHUB\CMAKE_ISSUE_CHECKLIBRARYEXIST\BUILD.64\CMAKEFILES\CMAKETMP\CMTC_7909E.DIR\DEBUG\CHECKFUNCTIONEXISTS.OBJ
/OUT:"E:\WORK\GITHUB\CMAKE_ISSUE_CHECKLIBRARYEXIST\BUILD.64\CMAKEFILES\CMAKETMP\DEBUG\CMTC_7909E.EXE"
/INCREMENTAL /NOLOGO KERNEL32.LIB USER32.LIB GDI32.LIB WINSPOOL.LIB
SHELL32.LIB OLE32.LIB OLEAUT32.LIB UUID.LIB COMDLG32.LIB ADVAPI32.LIB
CRYPT32.LIB /MANIFEST /MANIFESTUAC:"level='asInvoker'
uiAccess='false'" /manifest:embed /DEBUG
/PDB:"E:/WORK/GITHUB/CMAKE_ISSUE_CHECKLIBRARYEXIST/BUILD.64/CMAKEFILES/CMAKETMP/DEBUG/CMTC_7909E.PDB"
/SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"E:/WORK/GITHUB/CMAKE_ISSUE_CHECKLIBRARYEXIST/BUILD.64/CMAKEFILES/CMAKETMP/DEBUG/CMTC_7909E.LIB"
/MACHINE:X64  /machine:x64
CMTC_7909E.DIR\DEBUG\CHECKFUNCTIONEXISTS.OBJ
-------------------------------------------------------------

Dumpbin output
-------------------------------------------------------------
E:\WORK\github\cmake_issue_checklibraryexist\build.64\CMakeFiles\CMakeTmp\cmTC_7
909e.dir\Debug>dumpbin /SYMBOLS CheckFunctionExists.obj
Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file CheckFunctionExists.obj

File Type: COFF OBJECT

COFF SYMBOL TABLE
000 01045E92 ABS    notype       Static       | @comp.id
001 80000190 ABS    notype       Static       | @feat.00
002 00000000 SECT1  notype       Static       | .drectve
    Section length   30, #relocs    0, #linenums    0, checksum        0
004 00000000 SECT2  notype       Static       | .debug$S
    Section length  210, #relocs    4, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .debug$T
    Section length   88, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT4  notype       Static       | .text$mn
    Section length   4F, #relocs    1, #linenums    0, checksum DF4B9C22
00A 00000000 UNDEF  notype ()    External     | CertFreeCertificateContext
00B 00000000 SECT4  notype ()    External     | main
00C 00000000 UNDEF  notype ()    External     | _RTC_InitBase
00D 00000000 UNDEF  notype ()    External     | _RTC_Shutdown
00E 00000000 SECT4  notype       Label        | $LN4
00F 00000000 SECT5  notype       Static       | .xdata
    Section length    8, #relocs    0, #linenums    0, checksum 85724CC6
011 00000000 SECT5  notype       Static       | $unwind$main
012 00000000 SECT6  notype       Static       | .pdata
    Section length    C, #relocs    3, #linenums    0, checksum F0BDD041
014 00000000 SECT6  notype       Static       | $pdata$main
015 00000000 SECT7  notype       Static       | .rtc$IMZ
    Section length    8, #relocs    1, #linenums    0, checksum        0, select
ion    2 (pick any)
017 00000000 SECT7  notype       Static       | _RTC_InitBase.rtc$IMZ
018 00000000 SECT8  notype       Static       | .rtc$TMZ
    Section length    8, #relocs    1, #linenums    0, checksum        0, select
ion    2 (pick any)
01A 00000000 SECT8  notype       Static       | _RTC_Shutdown.rtc$TMZ

String Table Size = 0x80 bytes

  Summary

         210 .debug$S
          88 .debug$T
          30 .drectve
           C .pdata
           8 .rtc$IMZ
           8 .rtc$TMZ
          4F .text$mn
           8 .xdata

E:\WORK\github\cmake_issue_checklibraryexist\build.64\CMakeFiles\CMakeTmp\cmTC_7
909e.dir\Debug>

As I can see the difference is

  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c
/Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D
CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG /D
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_67614.dir\Debug\\"
/Fd"cmTC_67614.dir\Debug\vc140.pdb" /Gd /TC /analyze-
/errorReport:queue "C:\Program
Files\CMake\share\cmake-3.6\Modules\CheckFunctionExists.c"

  Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86

  Copyright (C) Microsoft Corporation.  All rights reserved.



  cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D
CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG /D
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_67614.dir\Debug\\"
/Fd"cmTC_67614.dir\Debug\vc140.pdb" /Gd /TC /analyze-
/errorReport:queue "C:\Program
Files\CMake\share\cmake-3.6\Modules\CheckFunctionExists.c"



  CheckFunctionExists.c

Link:

  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe
/ERRORREPORT:QUEUE
/OUT:"E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\Debug\cmTC_67614.exe"
/INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
crypt32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker'
uiAccess='false'" /manifest:embed /DEBUG
/PDB:"E:/WORK/github/cmake_issue_checklibraryexist/build.32/CMakeFiles/CMakeTmp/Debug/cmTC_67614.pdb"
/SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"E:/WORK/github/cmake_issue_checklibraryexist/build.32/CMakeFiles/CMakeTmp/Debug/cmTC_67614.lib"
/MACHINE:X86 /SAFESEH  /machine:X86
cmTC_67614.dir\Debug\CheckFunctionExists.obj

CheckFunctionExists.obj : error LNK2019: unresolved external symbol
_CertFreeCertificateContext referenced in function _main
[E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\cmTC_67614.vcxproj]

E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\Debug\cmTC_67614.exe
: fatal error LNK1120: 1 unresolved externals
[E:\WORK\github\cmake_issue_checklibraryexist\build.32\CMakeFiles\CMakeTmp\cmTC_67614.vcxproj]



00A 00000000 UNDEF  notype ()    External     | _CertFreeCertificateContext
for 32-bit

vs

ClCompile:

  C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\x86_amd64\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /D WIN32 /D
_WINDOWS /D CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG
/D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_7909e.dir\Debug\\"
/Fd"cmTC_7909e.dir\Debug\vc140.pdb" /Gd /TC /errorReport:queue
"C:\Program Files\CMake\share\cmake-3.6\Modules\CheckFunctionExists.c"

  Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64

  Copyright (C) Microsoft Corporation.  All rights reserved.



  cl /c /Zi /W3 /WX- /Od /Ob0 /D WIN32 /D _WINDOWS /D
CHECK_FUNCTION_EXISTS=CertFreeCertificateContext /D _DEBUG /D
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_7909e.dir\Debug\\"
/Fd"cmTC_7909e.dir\Debug\vc140.pdb" /Gd /TC /errorReport:queue
"C:\Program Files\CMake\share\cmake-3.6\Modules\CheckFunctionExists.c"



  CheckFunctionExists.c

Link:

  C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE
/OUT:"E:\WORK\github\cmake_issue_checklibraryexist\build.64\CMakeFiles\CMakeTmp\Debug\cmTC_7909e.exe"
/INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
crypt32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker'
uiAccess='false'" /manifest:embed /DEBUG
/PDB:"E:/WORK/github/cmake_issue_checklibraryexist/build.64/CMakeFiles/CMakeTmp/Debug/cmTC_7909e.pdb"
/SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"E:/WORK/github/cmake_issue_checklibraryexist/build.64/CMakeFiles/CMakeTmp/Debug/cmTC_7909e.lib"
/MACHINE:X64  /machine:x64
cmTC_7909e.dir\Debug\CheckFunctionExists.obj

  cmTC_7909e.vcxproj ->
E:\WORK\github\cmake_issue_checklibraryexist\build.64\CMakeFiles\CMakeTmp\Debug\cmTC_7909e.exe


00A 00000000 UNDEF  notype ()    External     | CertFreeCertificateContext
for 64-bit

> Thanks,
>
> --Ben


So looks like name mangling differs for different targets.

-- 
Best Regards,
Sergei Nikulov

From sergey.nikulov at gmail.com  Thu Jul 28 10:10:34 2016
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Thu, 28 Jul 2016 17:10:34 +0300
Subject: [cmake-developers] Strange behaviour with check_library_exists
	on Windows
In-Reply-To: <CAE7Ac0Cwi9zuX0L7sCJu-yEyh9d4GLV6yyauaX4eyUXXZCT5yw@mail.gmail.com>
References: <CAE7Ac0Ac4+EGtAuBcEjfArAWHpToy+Qtb5L9_T5rVGd+6P9WVw@mail.gmail.com>
 <20160728120304.GA17760@megas.kitware.com>
 <CAE7Ac0Cwi9zuX0L7sCJu-yEyh9d4GLV6yyauaX4eyUXXZCT5yw@mail.gmail.com>
Message-ID: <CAE7Ac0C5khrk8jUKBcVgnt0MW0MXT+huyHd-Vj0gQF8Wb5Q70A@mail.gmail.com>

2016-07-28 16:58 GMT+03:00 Sergei Nikulov <sergey.nikulov at gmail.com>:
> 2016-07-28 15:03 GMT+03:00 Ben Boeckel <ben.boeckel at kitware.com>:
>> On Thu, Jul 28, 2016 at 13:33:35 +0300, Sergei Nikulov wrote:
>>> -- Looking for CertFreeCertificateContext in crypt32;
>>> -- Looking for CertFreeCertificateContext in crypt32; - found
>>> crypt32 found
>>
>> These are tested using try_compile. Is there anything interesting under
>> CMakeFiles/CMakeTmp/* when you configure with --debug-trycompile? It
>> should contain the example files used and output from the compiler.
>>
>
> Ben,
>
> So looks like name mangling differs for different targets.

Yes.
Here the explanation
http://stackoverflow.com/questions/28062446/x64-dll-export-function-names

I think, for Windows try_compile should be fixed somehow with macros magic.

-- 
Best Regards,
Sergei Nikulov

From prlw1 at cam.ac.uk  Thu Jul 28 12:26:09 2016
From: prlw1 at cam.ac.uk (Patrick Welche)
Date: Thu, 28 Jul 2016 17:26:09 +0100
Subject: [cmake-developers] patches from pkgsrc
Message-ID: <20160728162612.9935-1-prlw1@cam.ac.uk>


While looking at updating cmake at:

  http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/cmake/README.html

I see that there are some patches which look useful, which I attach in
this series.

Cheers,

Patrick

From prlw1 at cam.ac.uk  Thu Jul 28 12:29:26 2016
From: prlw1 at cam.ac.uk (Patrick Welche)
Date: Thu, 28 Jul 2016 17:29:26 +0100
Subject: [cmake-developers] patch set
Message-ID: <20160728162926.GD15127@quartz>

It seems my patchset message didn't come through...

Those are patches from

  http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/cmake/README.html

which look as though they could be applied here.


Cheers,

Patrick

From prlw1 at cam.ac.uk  Thu Jul 28 12:26:12 2016
From: prlw1 at cam.ac.uk (Patrick Welche)
Date: Thu, 28 Jul 2016 17:26:12 +0100
Subject: [cmake-developers] [PATCH 3/3] Treat BSDs more uniformly.
In-Reply-To: <20160728162612.9935-1-prlw1@cam.ac.uk>
References: <20160728162612.9935-1-prlw1@cam.ac.uk>
Message-ID: <20160728162612.9935-4-prlw1@cam.ac.uk>

---
 Source/kwsys/SystemInformation.cxx | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 2965db8..29006e5 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -79,9 +79,9 @@ typedef int siginfo_t;
 # undef _WIN32
 #endif
 
-#ifdef __FreeBSD__
+#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__DragonFly__)
+# include <sys/param.h>
 # include <sys/sysctl.h>
-# include <fenv.h>
 # include <sys/socket.h>
 # include <netdb.h>
 # include <netinet/in.h>
@@ -89,21 +89,21 @@ typedef int siginfo_t;
 #  include <ifaddrs.h>
 #  define KWSYS_SYSTEMINFORMATION_IMPLEMENT_FQDN
 # endif
-#endif
-
-#if defined(__OpenBSD__) || defined(__NetBSD__)
-# include <sys/param.h>
-# include <sys/sysctl.h>
+# if defined(KWSYS_SYSTEMINFORMATION_HAS_BACKTRACE)
+#  include <execinfo.h>
+#  if defined(KWSYS_SYSTEMINFORMATION_HAS_CPP_DEMANGLE)
+#    include <cxxabi.h>
+#  endif
+#  if defined(KWSYS_SYSTEMINFORMATION_HAS_SYMBOL_LOOKUP)
+#    include <dlfcn.h>
+#  endif
+# endif
 #endif
 
 #if defined(KWSYS_SYS_HAS_MACHINE_CPU_H)
 # include <machine/cpu.h>
 #endif
 
-#if defined(__DragonFly__)
-# include <sys/sysctl.h>
-#endif
-
 #ifdef __APPLE__
 # include <sys/sysctl.h>
 # include <mach/vm_statistics.h>
-- 
2.9.2


From prlw1 at cam.ac.uk  Thu Jul 28 12:26:11 2016
From: prlw1 at cam.ac.uk (Patrick Welche)
Date: Thu, 28 Jul 2016 17:26:11 +0100
Subject: [cmake-developers] [PATCH 2/3] Use correct cmake macro.
In-Reply-To: <20160728162612.9935-1-prlw1@cam.ac.uk>
References: <20160728162612.9935-1-prlw1@cam.ac.uk>
Message-ID: <20160728162612.9935-3-prlw1@cam.ac.uk>

---
 Source/kwsys/SystemInformation.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 6c936e6..2965db8 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -4751,7 +4751,7 @@ bool SystemInformationImplementation::QuerySolarisMemory()
   // a 32 bit process on a 64 bit host the returned memory will be
   // limited to 4GiB. So if this is a 32 bit process or if the sysconf
   // method fails use the kstat interface.
-#if SIZEOF_VOID_P == 8
+#if CMAKE_SIZEOF_VOID_P == 8
   if (this->QueryMemoryBySysconf())
     {
     return true;
-- 
2.9.2


From prlw1 at cam.ac.uk  Thu Jul 28 12:26:10 2016
From: prlw1 at cam.ac.uk (Patrick Welche)
Date: Thu, 28 Jul 2016 17:26:10 +0100
Subject: [cmake-developers] [PATCH 1/3] SCO OpenServer 5.0.7/3.2 support
	From ryoon@netbsd.org in pkgsrc.org since 2014, plus one sun fix.
In-Reply-To: <20160728162612.9935-1-prlw1@cam.ac.uk>
References: <20160728162612.9935-1-prlw1@cam.ac.uk>
Message-ID: <20160728162612.9935-2-prlw1@cam.ac.uk>

---
 Modules/Platform/SCO_SV.cmake      |  1 +
 Source/cmELF.cxx                   | 14 ++++++++++++--
 Source/kwsys/SystemInformation.cxx |  2 +-
 Source/kwsys/SystemTools.cxx       |  5 +++++
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Modules/Platform/SCO_SV.cmake b/Modules/Platform/SCO_SV.cmake
index ddd9600..1cb4b38 100644
--- a/Modules/Platform/SCO_SV.cmake
+++ b/Modules/Platform/SCO_SV.cmake
@@ -1,2 +1,3 @@
 set(CMAKE_DL_LIBS "")
+set(CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-h,")
 include(Platform/UnixPaths)
diff --git a/Source/cmELF.cxx b/Source/cmELF.cxx
index 15755cb..ce3da30 100644
--- a/Source/cmELF.cxx
+++ b/Source/cmELF.cxx
@@ -46,6 +46,9 @@ typedef struct Elf32_Rela Elf32_Rela;
 #if defined(__sun)
 #include <sys/link.h> // For dynamic section information
 #endif
+#ifdef _SCO_DS
+#include <link.h> // For DT_SONAME etc.
+#endif
 
 // Low-level byte swapping implementation.
 template <size_t s>
@@ -214,6 +217,8 @@ struct cmELFTypes32
 };
 
 // Configure the implementation template for 64-bit ELF files.
+#ifndef _SCO_DS
+// SCO OpenServer 5.0.7/3.2 does not support 64-bit ELF.
 struct cmELFTypes64
 {
   typedef Elf64_Ehdr ELF_Ehdr;
@@ -223,6 +228,7 @@ struct cmELFTypes64
   typedef KWIML_INT_uint64_t tagtype;
   static const char* GetName() { return "64-bit"; }
 };
+#endif
 
 // Parser implementation template.
 template <class Types>
@@ -800,10 +806,14 @@ cmELF::cmELF(const char* fname)
   if (ident[EI_CLASS] == ELFCLASS32) {
     // 32-bit ELF
     this->Internal = new cmELFInternalImpl<cmELFTypes32>(this, fin, order);
-  } else if (ident[EI_CLASS] == ELFCLASS64) {
+  }
+#ifndef _SCO_DS
+  else if (ident[EI_CLASS] == ELFCLASS64) {
     // 64-bit ELF
     this->Internal = new cmELFInternalImpl<cmELFTypes64>(this, fin, order);
-  } else {
+  }
+#endif
+  else {
     this->ErrorMessage = "ELF file class is not 32-bit or 64-bit.";
     return;
   }
diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx
index 81fb2f9..6c936e6 100644
--- a/Source/kwsys/SystemInformation.cxx
+++ b/Source/kwsys/SystemInformation.cxx
@@ -123,7 +123,7 @@ typedef int siginfo_t;
 # endif
 #endif
 
-#ifdef __linux
+#if defined(__linux) || defined (__sun) || defined(_SCO_DS)
 # include <fenv.h>
 # include <sys/socket.h>
 # include <netdb.h>
diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index 0526372..c861d5a 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -1316,8 +1316,13 @@ bool SystemTools::FileExists(const std::string& filename)
             SystemTools::ConvertToWindowsExtendedPath(filename).c_str())
           != INVALID_FILE_ATTRIBUTES);
 #else
+// SCO OpenServer 5.0.7/3.2's command has 711 permission.
+#if defined(_SCO_DS)
+  return access(filename.c_str(), F_OK) == 0;
+#else
   return access(filename.c_str(), R_OK) == 0;
 #endif
+#endif
 }
 
 //----------------------------------------------------------------------------
-- 
2.9.2


From tobias.hunger at gmail.com  Fri Jul 29 06:01:42 2016
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Fri, 29 Jul 2016 12:01:42 +0200
Subject: [cmake-developers] cmake -E capabilities [attempt 2]
In-Reply-To: <nn8qni$4g1$1@ger.gmane.org>
References: <1469105598.765.32.camel@qt.io>
 <CAMdWP3E=UsXceRzb+L9C3gq-162_Nd+ZJdq9s=bNSe=ot3=XJA@mail.gmail.com>
 <nn8qni$4g1$1@ger.gmane.org>
Message-ID: <CAMdWP3H5q9Zk4e+VRfBevyCPOQ7Wa=CgM3SvB9pxRCKHh+mstA@mail.gmail.com>

Hi Stephen,

thanks for taking the time to do such a thorough review!

I pushed an update that takes most of the feedback into account. Still at:

https://github.com/hunger/CMake/commits/cmake-capabilities

On Wed, Jul 27, 2016 at 1:11 AM, Stephen Kelly <steveire at gmail.com> wrote:
> Tobias Hunger wrote:
>
>> Did anyone find some time for a review yet?
>
> Hi Tobias,
>
> I had a look through this this evening. Thanks for working on this. The
> commit adding the functionality at the end looks much better after the extra
> generator refactoring.
>
> Here are some review notes:
>
> * That commit has a cmDefinitions include though that should be removed.

Gone.

> * There are also some methods that should be const

Added const to some of them:-) Hope I caught all.

> * and a whitespace change that should be squashed into the commit that
> introduces it

I used Utilities/Scripts/clang-format.bash to do the formatting, so
that should not be an issue. I just reran that on all commits. Maybe I
forgot it in a commit or something before.

> * The pretty-print flag should be removed. Aside from being a boolean trap,
> it creates a interface segregation principle violation. See eg

Removed, even though I find it really useful when testing cmake on
mac/windows. I do have all the small helper tools on Linux, but
usually not on windows/Mac.

> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the
> capabilities handling:
>
> #if defined(CMAKE_BUILD_WITH_CMAKE)
>     else if (args[1] == "capabilities") {
>       cmake cm;
>       std::cout << cm.ReportCapabilities();
>       return 0;
>     }
> #endif

Why?

> That define should not be used in ReportCapabilities.

That define seems necessary to keep the bootstrap test running.

> * Splitting the 'CMake: Refactor ExtraGenerator registration' commit into
> multiple commits would make it more reviewable, and more bisectable in the
> future.

Sorry, this is what you will get from me: I have to start at some
place and meddle through till things work again. I have to back-track
often.

Basically I need to get some functionality implemented completely and
then test that. Only afterwards can I spend time on making the patches
pretty.

If that is not acceptable, then please feel free to do necessary
changes yourself.

> As it is, it is doing many different things, none of which are mentioned in
> the commit message, and some of which it probably shouldn't be doing.
>
> For example renaming GetExtraGeneratorName to
> GetExternalMakefileProjectGeneratorName is probably not needed. If you
> really want to do it, then it should be in its own commit with its own
> commit message which justifies the change. As it is, it adds noise to the
> big commit and makes it harder to review. Minimal is always better with
> commits which do refactoring like that.

I undid that change. That is one of the things that I originally
removed and then realized last minute that it is needed somehow. So I
added it, not realizing that I had removed similar functionality
earlier.

> A general good rule of thumb (which helps reviews, and makes things
> bisectable in the future) is to do one thing per commit.

I agree that this is the ideal we all should all strive for, but you
are not going to get that from me anytime soon. At least not in the
cmake codebase.

Best Regards,
Tobias

From konstantin at podsvirov.pro  Fri Jul 29 16:56:44 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Fri, 29 Jul 2016 23:56:44 +0300
Subject: [cmake-developers] [ISSUE] Bump to 3.2 and continue...
Message-ID: <2255351469825804@web5g.yandex.ru>

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

--
Regards,
Konstantin Podsvirov

From aoe at google.com  Fri Jul 29 17:44:45 2016
From: aoe at google.com (Chaoren Lin)
Date: Fri, 29 Jul 2016 14:44:45 -0700
Subject: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC
	toolchain.
Message-ID: <1469828685-28388-1-git-send-email-aoe@google.com>

Clang on Windows uses the GCC toolchain, so we need to avoid using
backslashes for paths in response files.
---
 Source/cmGlobalNinjaGenerator.cxx | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 51175c7..776a44f 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -558,7 +558,12 @@ void cmGlobalNinjaGenerator::EnableLanguage(
       strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
       strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 ||
       strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 ||
-      strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) {
+      strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0 ||
+      // Clang uses the GCC toolchain.
+      strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "Clang") == 0 ||
+      strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "Clang") == 0 ||
+      strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "Clang") == 0 ||
+      strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "Clang") == 0) {
     this->UsingGCCOnWindows = true;
   }
 #endif
-- 
2.8.0.rc3.226.g39d4020


From aoe at google.com  Fri Jul 29 17:44:52 2016
From: aoe at google.com (Chaoren Lin)
Date: Fri, 29 Jul 2016 14:44:52 -0700
Subject: [cmake-developers] [PATCH] Use full path for all source files in
	ninja build.
Message-ID: <1469828692-28544-1-git-send-email-aoe@google.com>

From: Chaoren Lin <chaorenl at google.com>

Relative paths are difficult for an IDE to parse the output of
a build error.
---
 Source/cmNinjaTargetGenerator.cxx | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Source/cmNinjaTargetGenerator.cxx b/Source/cmNinjaTargetGenerator.cxx
index 855a243..7849c5e 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -529,8 +529,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
   cmSourceFile const* source, bool writeOrderDependsTargetForTarget)
 {
   std::string const language = source->GetLanguage();
-  std::string const sourceFileName =
-    language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+  std::string const sourceFileName = source->GetFullPath();
   std::string const objectDir =
     this->ConvertToNinjaPath(this->GeneratorTarget->GetSupportDirectory());
   std::string const objectFileName =
-- 
2.8.0.rc3.226.g39d4020


From Simon.Richter at hogyros.de  Fri Jul 29 20:44:19 2016
From: Simon.Richter at hogyros.de (Simon Richter)
Date: Sat, 30 Jul 2016 02:44:19 +0200
Subject: [cmake-developers] VS 2015,
	long command line in ResourceCompile invocation
Message-ID: <429c0e93-027b-7425-07cf-bea12115126d@hogyros.de>

Hi,

I have a build that fails with

C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(1320,5):
warning MSB6002: Die Befehlszeile f?r die RC-Aufgabe ist zu lang. Bei
Befehlszeilen mit mehr als 32000 Zeichen treten h?ufig Fehler auf.
Versuchen Sie, die Befehlszeile zu k?rzen, indem Sie den Aufruf von RC
in mehrere Aufrufe mit weniger Parametern pro Aufruf unterteilen.
[C:\Jenkins\workspace\windows-oce-msvc-head\build\release\cpu\x86\label\windows\adm\cmake\TKOffset\TKOffset.vcxproj]

C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(1320,5):
error MSB6003: Die angegebene ausf?hrbare Datei der Aufgabe "rc.exe"
konnte nicht ausgef?hrt werden. Der Dateiname oder die Erweiterung ist
zu lang
[C:\Jenkins\workspace\windows-oce-msvc-head\build\release\cpu\x86\label\windows\adm\cmake\TKOffset\TKOffset.vcxproj]

The full build log is at

http://ci.kicad-pcb.org/job/windows-oce-msvc-head/build=release,cpu=x86,label=windows/6/consoleFull

Is there a way to make VS use a response file here?

   Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160730/59904a5c/attachment.sig>

From k.sinitsyn at gmail.com  Fri Jul 29 23:10:04 2016
From: k.sinitsyn at gmail.com (Konstantin Sinitsyn)
Date: Fri, 29 Jul 2016 20:10:04 -0700
Subject: [cmake-developers] FindProtobuf backward compatibility issue for
	PROTOBUF_IMPORT_DIRS
Message-ID: <CAJOj3G9yfN4QUNu3c4WVGiN5qYnvGcRDq-fnin=yh7JNheYqqw@mail.gmail.com>

After recent changes in FindProtobuf.cmake protobuf_generate_cpp doesn't
take into account PROTOBUF_IMPORT_DIRS (in upper case) anymore.

The issue was introduced by this change:
http://public.kitware.com/pipermail/cmake-developers/2016-March/027910.html
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7b09e7f

As far as I understand issue is caused by the fact that code that changes
uppercase to camelcase is executed only when we call find_package, but the
way it's sometimes used is

find_package(Protobuf REQUIRED)

set(PROTOBUF_IMPORT_DIRS ./includedir1)
protobuf_generate_cpp(SRCS1 HDRS1 PROTOS2)

set(PROTOBUF_IMPORT_DIRS ./includedir2)
protobuf_generate_cpp(SRCS2 HDRS2 PROTOS2)

set(PROTOBUF_IMPORT_DIRS ./includedir3)
protobuf_generate_cpp(SRCS3 HDRS3 PROTOS3)

But now protobuf_generate_cpp only looks at camel case variable.


Here's the patch to fix this:

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index c90a0a2..6c04de3 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -129,6 +129,10 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS)
     set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
   endif()

+  if(DEFINED PROTOBUF_IMPORT_DIRS AND NOT DEFINED Protobuf_IMPORT_DIRS)
+    set(Protobuf_IMPORT_DIRS ${PROTOBUF_IMPORT_DIRS})
+  endif()
+
   if(DEFINED Protobuf_IMPORT_DIRS)
     foreach(DIR ${Protobuf_IMPORT_DIRS})
       get_filename_component(ABS_PATH ${DIR} ABSOLUTE)
@@ -187,6 +191,10 @@ function(PROTOBUF_GENERATE_PYTHON SRCS)
     set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
   endif()

+  if(DEFINED PROTOBUF_IMPORT_DIRS AND NOT DEFINED Protobuf_IMPORT_DIRS)
+    set(Protobuf_IMPORT_DIRS ${PROTOBUF_IMPORT_DIRS})
+  endif()
+
   if(DEFINED Protobuf_IMPORT_DIRS)
     foreach(DIR ${Protobuf_IMPORT_DIRS})
       get_filename_component(ABS_PATH ${DIR} ABSOLUTE)

~
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160729/07a2e062/attachment.html>

From david.keller at litchis.fr  Sat Jul 30 10:48:53 2016
From: david.keller at litchis.fr (David Keller)
Date: Sat, 30 Jul 2016 16:48:53 +0200
Subject: [cmake-developers] [PATCH] Allow custom osx framework locations.
Message-ID: <20160730144853.26891-1-david.keller@litchis.fr>

This allows non-standard locations to be searched, e.g. brew, port.

Signed-off-by: David Keller <david.keller at litchis.fr>
---
 Modules/CMakeFindFrameworks.cmake | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeFindFrameworks.cmake b/Modules/CMakeFindFrameworks.cmake
index 6a8bcd4..80eb003 100644
--- a/Modules/CMakeFindFrameworks.cmake
+++ b/Modules/CMakeFindFrameworks.cmake
@@ -3,6 +3,10 @@
 # -------------------
 #
 # helper module to find OSX frameworks
+#
+# This module reads hints about search locations from variables::
+#
+#   CMAKE_FIND_FRAMEWORK_EXTRA_LOCATIONS - Extra directories
 
 #=============================================================================
 # Copyright 2003-2009 Kitware, Inc.
@@ -24,9 +28,11 @@ if(NOT CMAKE_FIND_FRAMEWORKS_INCLUDED)
     if(APPLE)
       foreach(dir
           ~/Library/Frameworks/${fwk}.framework
+          /usr/local/Frameworks/${fwk}.framework
           /Library/Frameworks/${fwk}.framework
           /System/Library/Frameworks/${fwk}.framework
-          /Network/Library/Frameworks/${fwk}.framework)
+          /Network/Library/Frameworks/${fwk}.framework
+          ${CMAKE_FIND_FRAMEWORK_EXTRA_LOCATIONS})
         if(EXISTS ${dir})
           set(${fwk}_FRAMEWORKS ${${fwk}_FRAMEWORKS} ${dir})
         endif()
-- 
2.7.4 (Apple Git-66)


From seblist at xwmw.org  Sun Jul 31 12:49:49 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Sun, 31 Jul 2016 18:49:49 +0200
Subject: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
Message-ID: <fb33d834-fc7a-3411-6997-79c0ce5e5b06@xwmw.org>

Hi,

I have updated the patch for CMake 3.6.0 to fix
https://gitlab.kitware.com/cmake/cmake/issues/16209
This patch introduces a new class cmFilePathUuid which
is used in QtAutogen to generated unique filenames.
The name generation algorithm is the same as in
http://public.kitware.com/pipermail/cmake-developers/2016-July/029087.html
but the paths initialization moved to the class constructor
- which also accepts a cmMakefile pointer.

Please review.

-Sebastian

P.S.
I'm just an enthusiastic amateur doing this in my spare time.
Please apologize me if I can't reply immediately.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-QtAutogen-fix-for-too-deep-nested-directory-ge_V001.patch
Type: text/x-patch
Size: 24617 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160731/fb84adcf/attachment.bin>

From seblist at xwmw.org  Sun Jul 31 15:56:13 2016
From: seblist at xwmw.org (Sebastian Holtermann)
Date: Sun, 31 Jul 2016 21:56:13 +0200
Subject: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow
 patch
In-Reply-To: <fb33d834-fc7a-3411-6997-79c0ce5e5b06@xwmw.org>
References: <fb33d834-fc7a-3411-6997-79c0ce5e5b06@xwmw.org>
Message-ID: <695ab7bc-0e4d-aa9b-3198-7e77056830d3@xwmw.org>

Am 31.07.2016 um 18:49 schrieb Sebastian Holtermann:
> Hi,
>
> I have updated the patch for CMake 3.6.0 to fix
> https://gitlab.kitware.com/cmake/cmake/issues/16209
> This patch introduces a new class cmFilePathUuid which
> is used in QtAutogen to generated unique filenames.
> The name generation algorithm is the same as in
> http://public.kitware.com/pipermail/cmake-developers/2016-July/029087.html
> but the paths initialization moved to the class constructor
> - which also accepts a cmMakefile pointer.
>
> Please review.

There was a path conversion missing.
Here is an updated patch.

-Sebastian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-QtAutogen-fix-for-too-deep-nested-directory-ge_V002.patch
Type: text/x-patch
Size: 24716 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160731/eaec55c4/attachment-0001.bin>