Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles |
| Date | |
| Msg-id | CABUevEz2aaLKBTnX-69MioUJUnui97B=k2oJEVhBNTxxOB+A=w@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles
(Heikki Linnakangas <hlinnaka@iki.fi>)
Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles (Andres Freund <andres@anarazel.de>) |
| List | pgsql-hackers |
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- Andres Freund <andres@anarazel.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@sss.pgh.pa.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).
pgsql-hackers by date: