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

On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.
>

Is it broken in HEAD only or also in 9.6?

I think whomever uses win32.mak to build is quite unlikely to be tracking
HEAD. They would notice at release time. (Since we don't have a buildfarm
animal doing it)

> 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.
>

Insurmountable, probably not. The big difference is that you don't need
*any* dependencies to build a libpq using win32.mak, but you need many of
them (to start with, perl...) to build using the built-in one. For people
who want to build it, it certainly save a lot more than "a few minutes".
For somebody who doesn't have ready scripts it takes a *long* time to set
up a build environment to do our regular msvc builds.

I think the question is more, is there any need for people to do that at
all, or are those people just going to be using the pre-built binaries
anyway? That question I can't say I know the answer to.

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.
>

I think there's always been even fewer users of bcc32.mak than of the
win32.mak one.

> 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.
>

The compiler is still called bcc (bcc32c to be specific - see
https://www.embarcadero.com/free-tools/ccompiler). Apparently it's clang
based now. I don't know if our mak file even works with that anymore
though, it wouldn't surprise me if it doesn't. But the non-change-of-name
could be why we're not seeing questions about it.

FWIW, I've suggested we drop it before, so no objections to that part from
me (and if we do, there's some #ifdefs around it in headers as well).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/