Re: [HACKERS] int 8 on FreeBSD
От | Holm Tiffe |
---|---|
Тема | Re: [HACKERS] int 8 on FreeBSD |
Дата | |
Msg-id | 19990303133825.A20856@pegasus.freibergnet.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] int 8 on FreeBSD (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] int 8 on FreeBSD
|
Список | pgsql-hackers |
The Hermit Hacker wrote: > On Wed, 3 Mar 1999, Holm Tiffe wrote: > > > Hi all, > > [..] > > > > BTW: why the configure script think's that tcl and tk includes > > (tclConfig.sh,tkConfig.sh) must reside in the same directory ? > > That's really an odd assumtion. > > Its only an odd assumption to those on FreeBSD...we tend to be the only > ones that pervert most of the "standards" as far as installation > directories are concerned, and require specific handholding to get things > to install :( ..but it is possible on FreeBSD to run several different tcl/tk pairs in parallel, so it turns out that it is the better way and I can't remeber that I have had such problems with an other package. Personally I HATE GNU's autoconf, it is really a pain to get things working on "non standard environments". I prefer a Makefile in which I can set options directly. But this is my own opinion and I can understand why others doesn't think so. > > See /usr/ports/databases/postgresql/Makefile, where it provides the > various --with-tcl= directives required... Yeah, I've build PGSQL without the ports, because there was no port of 6.4.2 to the time I needed it, and I've got it finally working. Another question: Watfor is the patches directory on ftp.postgresql.org/pub ? It contains almost nothing of the actual patches from the -patches mailinglist. This makes it really not simple to get a halfways actual setup without sup/cvsup or so... Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher & Partner fax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
В списке pgsql-hackers по дате отправления: