On 04/11/2016 03:47 AM, Michael Paquier wrote:
> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> Now, I have produced two patches:
>> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>> __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
>> hack, though I am coming to think that this may be the approach that
>> would us the less harm, and that's closer to what is done for VS 2012
>> and 2013.
>> - 0001-Support-for-VS-2015-getlocaleinfoex.patch, which make use of
>> GetLocaleInfoEx, this requires us to lower a bit the support grid for
>> Windows, basically that's throwing support for XP if compilation is
>> done with VS 2015.
>> Based on my tests, both are working with short and long local names,
>> testing via initdb --locale.
> The first patch is actually not what I wanted to send. Here are the
> correct ones...
I think I prefer the less hacky solution.
Progress report:
1. My VS 2015 installations (I now have several) all generate solution
file with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as the solution file version.
2. The logic in win32.h is a bit convoluted. I'm going to simplify it.
3. I'm going to define _WINSOCK_DEPRECATED_NO_WARNINGS to silence some
compiler bleatings about the way we use the Winsock API
4. The compiler complains about one of Microsoft's own header files -
essentially it dislikes the=is construct:
typedef enum { ... };
It would be nice to make it shut up about it.
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
5. most importantly, on my Release/X64 build, I am getting a regression
failure on contrib/seg. regression diffs attached. Until that's fixed
this isn't going anywhere.
cheers
andrew
