Re: VS 2015 support in src/tools/msvc

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: VS 2015 support in src/tools/msvc
Дата
Msg-id CABUevEwJrjKqrJ=XWyDgnAzUBvBbFrf=RLHvaaXqQOUSkrmaLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: VS 2015 support in src/tools/msvc  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: VS 2015 support in src/tools/msvc  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Mar 3, 2016 at 6:18 PM, Andrew Dunstan <andrew@dunslane.net> wrote:


On 03/03/2016 09:02 AM, Michael Paquier wrote:
Hi all,

Microsoft provides a set of VMs that one can use for testing and
Windows 10 is in the set:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
I have grabbed one and installed the community version of Visual
Studio 2015 so I think that I am going to be able to compile Postgres
with VS2015 with a bit of black magic.

My goal is double:
1) As far as things have been discussed, VS2015 is making difficult
the compilation of Postgres, particularly for locales. So I'd like to
see what are the problems behind that and see if we can patch it
properly. This would facilitate the integration of cmake as well for
Windows.
2) src/tools/msvc stuff has support only up to VS2013. I think that it
would be nice to bump that a bit and get something for 9.5~.

So, would there be interest for a patch on the perl scripts in
src/tools/msvc or are they considered a lost cause? Having a look at
the failures could be done with the cmake work, but it seems a bit
premature to me to look at that for the moment, and having support for
VS2015 with 9.5 (support for new versions of VS won a backpatch the
last couple of years) would be a good thing I think.



I am not holding my breath on cmake. Until we have something pretty solid on that front I'm going to assume it's not happening. If we're going to support VS2015 (and I think we should) then it should be supported for all live branches if possible. I'm assuming the changes would be pretty localized, at least in src/tools/msvc, and adding a new compile shouldn't break anything with existing compilers.


+1.

Definitely do it for HEAD.

Then if it gets backpatched is going to depend on the locality I think. If it's just the build system then it should be no problem, but I thought Michael also suggested some API changes. If that's so, then it is going to depend on how invasive those are. But that part should be done for HEAD regardless, so it's definitely worth the effort to figure out exactly what it involves.


--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: improving GROUP BY estimation
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pg_basebackup compression TODO item