Re: VS 2015 support in src/tools/msvc

On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
> 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.

OK cool, we could go with something else than sed to generate probes.h
but that seems sensible considering that this should definitely be
back-patched. Not sure what the others think about adding a new file
in the source tarball by default though.

>> - 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.

MinGW would react to that correctly I think. If I look at
mingw/include/timezone.h, both timezone and _timezone are defined. I
would think that this is intentional to declare both there.

>> - 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.

I am open to more fancy solutions if it is possible to get reliably
the codepage in a different way, but I am not sure this is worth the
complication. The pre-VS2012 code has been able to live with that.
--
Michael