From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | Christian Ullrich <chris(at)chrullrich(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VS 2015 support in src/tools/msvc |
Date: | 2016-04-21 19:39:05 |
Message-ID: | 57192C59.9090903@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/11/2016 03:47 AM, Michael Paquier wrote:
> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
seg-regression.diffs | text/plain | 8.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-04-21 19:47:08 | Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. |
Previous Message | Alvaro Herrera | 2016-04-21 19:31:13 | Re: kqueue |