Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Yury Zhuravlev
Michael Paquier wrote: Well, 2015 is not making things easy visibly by not providing direct ways to get locale information. pgwin32_putenv broken too... -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Michael Paquier
On Thu, Jan 28, 2016 at 8:51 PM, Yury Zhuravlev wrote: > Craig Ringer wrote: >> >> I strongly disagree. MSVC is a high quality compiler and the primary tool >> for the platform. > > Ok. And we not suport MSVC2015 now. Either we support the platform normally > or

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Yury Zhuravlev
Michael Paquier wrote: Many companies use it, including mine, and likely EDB. Ok, why? I wonder why it is? -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Yury Zhuravlev
So even if the main packages switched to compiling with mingw, we'd probably still want to support MSVC. MinGV more accessible. We can always say that after the release of X is not supported by the MSVC. I do not propose to abandon the MSVC but its use to be justified. Are we moving forward

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Yury Zhuravlev
Craig Ringer wrote: Yeah, strongly agree there. CMake has excellent MSVC support btw. Yes... but I found only hack way for call gendef.pl in pre_link stage (get objects folder name). CMake suggests that we use for normal MSVC ways to create dll. OTOH MinGW relies on reverse-engineered

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-28 Thread Yury Zhuravlev
Craig Ringer wrote: I strongly disagree. MSVC is a high quality compiler and the primary tool for the platform. Ok. And we not suport MSVC2015 now. Either we support the platform normally or throwing it. Now it all looks like a zombie. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-27 Thread Andres Freund
On 2016-01-27 21:05:06 +0800, Craig Ringer wrote: > On 27 January 2016 at 20:54, Alvaro Herrera > wrote: > > > If so many problems with MSVC can discard his support of Postgres? > I strongly disagree. MSVC is a high quality compiler and the primary tool > for the

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-27 Thread Yury Zhuravlev
Craig Ringer wrote: On 27 January 2016 at 00:16, Yury Zhuravlev wrote: It says more about the modules, and not about libpq. Using gendef.pl for this library in the light of the development of my CMake build seems silly. For what it's worth I personally agree.

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-27 Thread Alvaro Herrera
Yury Zhuravlev wrote: > If so many problems with MSVC can discard his support of Postgres? That doesn't sound likely. Keep in mind that users might want to compile extension modules, and not everyone is going to use mingw for that. As far as I know, stuff compiled with MSVC is not compatible

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-27 Thread Michael Paquier
On Wed, Jan 27, 2016 at 9:30 PM, Yury Zhuravlev wrote: > What's the point now support the MSVC? Many companies use it, including mine, and likely EDB. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-27 Thread Craig Ringer
On 27 January 2016 at 20:54, Alvaro Herrera wrote: > > If so many problems with MSVC can discard his support of Postgres? > I strongly disagree. MSVC is a high quality compiler and the primary tool for the platform. Yes, it's behind on standards support and that's

[HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-26 Thread Yury Zhuravlev
Hello hackers. Why we do not use PGDLLEXPORT (__declspec (dllexport)) for the libpq (and other dlls)? Now we are using black magic with gendef.pl for get def (aka export.txt) from .obj files. I have set for some functions and it works. Perhaps there is a circumstance that I do not know but my

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-26 Thread Craig Ringer
On 26 January 2016 at 23:04, Yury Zhuravlev wrote: > Hello hackers. > Why we do not use PGDLLEXPORT (__declspec (dllexport)) for the libpq (and > other dlls)? > Now we are using black magic with gendef.pl for get def (aka export.txt) > from .obj files. > I have set

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-26 Thread Yury Zhuravlev
Craig Ringer wrote: TL;DR: PGDLLEXPORT is considered ugly Windows-droppings in the code and so a less visible, albeit more convoluted, solution is used. It says more about the modules, and not about libpq. Using gendef.pl for this library in the light of the development of my CMake build

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

2016-01-26 Thread Craig Ringer
On 27 January 2016 at 00:16, Yury Zhuravlev wrote: > It says more about the modules, and not about libpq. Using gendef.pl for > this library in the light of the development of my CMake build seems silly. > > For what it's worth I personally agree. I'd rather have