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

Re: [HACKERS] Problem compiling postgres sql --with-tcl

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Problem compiling postgres sql --with-tcl
Date: 2001-12-17 13:43:10
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4212869@m0114.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Zeugswetter Andreas SB SD writes:
> >> Second I do not understand why the Makefile in pl/tcl is so complicated,
> >> and not similar e.g. to the plpython one, so the first task should be to
> >> simplify the Makefile to use Makefile.shlib, and not cook it's own soup.
> 
> > All the oddities in that makefile are there because presumably some system
> > needed them in the past.
> 
> No, it's a historical thing: the Makefile.shlib stuff didn't exist when
> pltcl was developed.  I'm not entirely sure why I didn't try to fold
> pltcl in with the Makefile.shlib approach when we started doing that.
> Possibly I was just thinking "don't fix what ain't broken".  But now
> I'd vote for changing over.

Here is a patch per above thread.
I tested the getDBs function in pgtclsh and a simple pltcl function.

I duplicated the file mkMakefile.tcldefs.sh which is probably not good,
but bin/pgtclsh already did it like that, so ...

Andreas

Attachment: tcl.patch
Description: application/octet-stream (6.0 KB)

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-12-17 14:12:53
Subject: Re: 7.2 is slow?
Previous:From: bpalmerDate: 2001-12-17 13:06:54
Subject: Re: 7.2 is slow?

pgsql-patches by date

Next:From: Brent VernerDate: 2001-12-17 14:19:54
Subject: Re: system catalog relation of a table and a serial sequence
Previous:From: Bruce MomjianDate: 2001-12-17 07:43:48
Subject: Re: SunOS patch for memcmp()

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