Skip site navigation (1) Skip section navigation (2)

Re: pg_config MSVC makefile

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>,"Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_config MSVC makefile
Date: 2005-01-07 16:36:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] 
> Sent: 07 January 2005 16:25
> To: Bruce Momjian
> Cc: Dave Page; Andrew Dunstan; Patches (PostgreSQL)
> Subject: Re: [PATCHES] pg_config MSVC makefile 
> > more of a pain.  If people are submitting patches it means they are
> > using them so they should be kept.
> Is anyone doing so though?

Not that I've seen.

> I recall proposing a couple months ago that we kill those makefiles,
> but there was at least one objection at the time.
> It occurs to me that the availability of the native port 
> might actually
> increase rather than decrease the demand for these makefiles --- or at
> least the demand for the ability to build libpq that way.  Consider
> people who are building database-using apps using MSVC or Borland.

They don't need to build libpq themselves though - we provide import
libs with the installer for VC++ that allows the supplied mingw build of
the dll to be used (that's how pgAdmin is built). I'm sure that a
Borland lib could be generated in the same way if anyone had the
equivalent Borland tool (with VC++  we use lib.exe).

My main concern is that they don't end up suffering terminal bit-rot
because I stop helping maintain them - if we ship them, they should

Regards, Dave.


pgsql-patches by date

Next:From: Tom LaneDate: 2005-01-07 17:06:31
Subject: Re: pg_config MSVC makefile
Previous:From: Tom LaneDate: 2005-01-07 16:25:14
Subject: Re: pg_config MSVC makefile

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group