Re: So, can we stop supporting Windows native now?
От | Michael Paquier |
---|---|
Тема | Re: So, can we stop supporting Windows native now? |
Дата | |
Msg-id | CAB7nPqQ7WeGmh7Td4z0LPhuy6bkMPV1jAJXaWjRRu7CGBmscJA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: So, can we stop supporting Windows native now? (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-hackers |
On Fri, Apr 1, 2016 at 9:05 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > I completely agree there. I wrote some documentation on how to make project > files to build extensions, but it'd be nice to *generate* them instead, like > we do for in-tree builds. Yes, I maintain some code that builds extension on Windows, those are using the msvc scripts by linking to the tree directly, with some custom-made wrappers for the calls that cannot be exported. That's ugly, but anybody would have guessed that.. > The problem is that we don't install all the Perl build stuff on Windows, > it's only in the build tree. The time consuming part wx is > / sll be cleaning that up so it can run outside src/tools/msvc, getting it > to use pg_config, and making it installable. Then of course there's the > issue that it won't be available before 9.7 at the soonest... unless some > brave soul backports it as an installable add-on. Which means extension > authors are still screwed for 5+ years. That's the main reason I haven't > tackled it - so far I've got by pretty well with VS project files + property > sheets, and any PGXS-like capability almost certainly couldn't be backported > so it's nearly useless for about 5 years. Still, it would be interesting to see how cmake affects this area of the code before tackling anything, doing something now may be time wasted for nothing at the end. So I would refrain from even putting resources in this project. -- Michael
В списке pgsql-hackers по дате отправления: