Re: src/interfaces/libpq shipping nmake-related Makefiles

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
>> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Still, it's not very clear why we need to cater for building just libpq
>>> rather than the whole distribution, and a user of win32.mak presumably
>>> has the option to do the latter.

>> Indeed. Those recent reports indicate that removing win32.c would be a
>> bad move.

> For me they indicate the contrary, that we're currently not properly
> maintaining it so that longstanding errors crop up.

Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.

bcc32.mak is in a different category because it's basically the only
solution if you want to build libpq in Borland C. But the lack of
user input suggests that maybe nobody cares about that anymore.

Borland C, per se, has been dead since the 90s according to wikipedia.
There are successor products with different names, none of which I can
recall anybody ever mentioning on the PG lists. I speculate that
people are taking libpq.dll built with MSVC and using it in those
products, if they're using them with PG at all.

regards, tom lane