On Fri, Apr 22, 2016 at 4:39 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> 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.
OK, at least we go in one direction.
> 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.
I am wondering why it happens this way for you..
> 2. The logic in win32.h is a bit convoluted. I'm going to simplify it.
OK. Should I wait for a patch to look at then?
> 3. I'm going to define _WINSOCK_DEPRECATED_NO_WARNINGS to silence some
> compiler bleatings about the way we use the Winsock API
Agreed here. I saw those warnings as well.
> 6. 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.
Hm. I am now looking at that, and I can reproduce the failure... I
will send a patch soon.
--
Michael
