Re: VS 2015 support in src/tools/msvc

On 04/03/16 15:23, Michael Paquier wrote:
>
> OK, attached are a set of patches that allowed me to compile Postgres
> using VS2015, in more details:
> - 0001, as mentioned by Petr upthread, psed is removed from the core
> distribution of Perl in 5.22, so when installing ActivePerl it is not
> possible to create probes.h, and the code compilation would fail. I
> bumped into that so here is a patch. What I am proposing here is to
> replace psed by sed, sed being available in MSYS like bison and flex,
> so when building using MSVC the environment to set up is normally
> already good to go even with this additional dependency. Now, it is
> important to mention that probes.h is not part of a source tarball. I
> think that we would want probes.h to be part of a source tarball so as
> it would be possible to compile the code on Windows using MSVC without
> having to install MSYS. I haven't done that in this patch, thoughts on
> the matter are welcome.

I vote for just using sed considering we need flex and bison anyway.

> - 0003, to address a compilation failure that I bumped into when
> compiling ecpg. In src/port, TIMEZONE_GLOBAL and TZNAME_GLOBAL refer
> to respectively timezone and tzname, however for win32, those should
> be _timezone and _tzname. See here:
> https://msdn.microsoft.com/en-us/library/htb3tdkc.aspx

Yep I hit that one as well, looks good.

> - 0004, which is to address the problem of the missing lc_codepage
> from locale.h in src/port/. I have been pondering about the use of
> more fancy routines like GetLocaleInfoEx as mentioned by Petr
> upthread. However, I think that we had better avoid any kind of
> complication and just fall back to the old code path should _MSC_VER
>> = 1900. We could always reuse lc_codepage if it gets reintroduced in
> a future version of VS.

Well I am worried that this way we might break existing installs which 
means we can't backpatch this. The problem here is that the fallback 
code does not support the <language>-<REGION> format which Microsoft 
documents everywhere as recommended locale format. The good news is that 
our own initdb won't auto-generate those when no locale was specified as 
it uses the setlocale() which returns the legacy (and not recommended) 
locale names and our fallback code can handle those. But manually set 
locales can be a problem.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services