Re: VS 2015 support in src/tools/msvc

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