From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Rod Taylor <pg@rbt.ca>
Subject: Re: Server Side C programming Environment Set up
Date: Fri, 23 Apr 2004 10:45:43 +0200
User-Agent: KMail/1.5.4
Cc: Kemin Zhou <kemin.zhou@ferring.com>, pgsql-sql@postgresql.org
References: <4086B601.3030108@ferring.com> <1082642297.91360.9.camel@jester>
	<7546.1082650023@sss.pgh.pa.us>
In-Reply-To: <7546.1082650023@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200404231045.43614.peter_e@gmx.net>

Am Donnerstag, 22. April 2004 18:07 schrieb Tom Lane:
> I agree with the suggestion elsewhere in the thread about generalizing
> the contrib Makefile framework to the point that it could be installed
> as part of the -devel RPM, and then used to build user-written backend
> functions.

It seems to me that you are proposing to recreate the same sort of framework 
that we have fought for years to get rid of in the cases of Perl, Python, and 
others.  Some reasons for why this is not a good idea are:

It would restrict users of that framework to use the same compiler that was 
used to build PostgreSQL.  History shows that this assumptions fails 
surprisingly often.

When someone wants to build a glue module between PostgreSQL and some other 
largish package (say, Perl, although that one exists already), then whose 
framework do you use?  Sometimes building outside of these frameworks becomes 
extremely difficult.

Without a configuration routine of its own, add-on packages are restricted to 
using the information that the main PostgreSQL configuration already 
provides.  If someone needs to detect or evaluate additional libraries there 
is no chance.

I'd be happy to write more documentation, howtos, or scripts and tools that 
enable users to set up a proper build system, but I don't think it's our 
business to try to write our own build system framework.