Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles
Date
Msg-id 29375.1491535211@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
> win32.mak in src/interfaces/libpq. To put it short: those files are
> not up to date. The code of SCRAM is in the tree for a bit of time
> now, and should have updated those files to list and clean up objects,
> but nobody has reported failures in using them.

> At the minimum, they should be updated. Or perhaps they could just be
> ripped out? Who uses that on Windows now?

I'm quite sure no developers use them, or have done so for years.
The ostensible point is to support people who are trying to build
just libpq on Windows, for use in applications talking to PG servers
elsewhere.  It was reasonable that some users would want to
do that back when we didn't have a credible native port of the server,
but it's been quite some time since that was true.

In short, I think we could rip them out without much push-back.
But maybe I'm missing some remaining use-case.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] No-op case in ExecEvalConvertRowtype
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] No-op case in ExecEvalConvertRowtype