2017-01-12 11:48 GMT+02:00 Charles Huet :
[...]
> Lua is the language that should be used, since it is easy to embed on all
> the platforms CMake supports. All arguments about language X being better
> than language Y do not matter, since all other languages do not answer to
> the constraints that
2016-08-17 16:47 GMT+03:00 Brad King :
> I squashed in one warning fix:
>
> Windows: Encode child process output to internally-used encoding
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12924660
>
> However, then I had to revert the change from `next` because it
> causes the CTest.Update
2016-08-16 21:09 GMT+03:00 Brad King :
> On 08/15/2016 04:34 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_DEF
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/CMakeLists.txt | 6 ++
Source/ProcessOutput.cxx | 141 +
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/CMakeLists.txt | 2 +
Source/ProcessOutput.hxx.in| 160 ++
2016-08-02 20:11 GMT+03:00 Brad King :
>
> How are we to know the encoding being produced by the child?
>
There isn't any reliable way to detect it, we just have to know what particular
application uses. Also there aren't any standard or API to determine it but
generally most applications use cons
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.
---
2016-07-21 20:46 GMT+03:00 Brad King :
> 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_Wa
2016-07-18 17:04 GMT+03:00 Brad King :
> 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_
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/cmPro
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 ++
Sou
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
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
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.
---
2016-07-08 16:04 GMT+03:00 Brad King :
> 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.
>&
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 | 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
---
Source/CPack/cmCPackGenerator.cxx | 8 +++---
Source/CTest/cmCTestCoverageHandler.cxx | 12 -
Source/CTest/cmCTestCurl.cxx| 27 ++--
Source/CTest/cmCTestMultiProcessHandler.cxx | 8 +++---
Source/cmBuildCommand.cxx | 25
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/cmProcessT
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 +++
2016-07-07 3:51 GMT+03:00 Mike Gelfand :
> On 07/07/2016 03:33 AM, Dāvis Mosāns wrote:
>> 2016-07-07 1:22 GMT+03:00 Mike Gelfand :
>>>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@
>>>> [snip]
>>>>private:
>>>> internal_buffe
s 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 fin
2016-07-07 1:22 GMT+03:00 Mike Gelfand :
>
> 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>
> >
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 file
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/Syst
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/S
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 ++-
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 +++
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.
---
---
Source/CPack/cmCPackGenerator.cxx | 8 +++---
Source/CTest/cmCTestCoverageHandler.cxx | 12 -
Source/CTest/cmCTestCurl.cxx| 27 ++--
Source/CTest/cmCTestMultiProcessHandler.cxx | 8 +++---
Source/cmBuildCommand.cxx | 25
2016-07-03 13:04 GMT+03:00 Mike Gelfand :
> 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 impl
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
2016-07-01 17:41 GMT+03:00 Mike Gelfand :
>
> 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
2016-07-01 15:25 GMT+03:00 Daniel Pfeifer :
> Hi Dāvis,
>
> On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns 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 t
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 u
35 matches
Mail list logo
