
I just built and regression tested the current source tree on both Solaris
x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
smooth...

Any arguments against getting a BETA2 out tomorrow afternoon?  

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org                    
scrappy@{postgresql|isc}.org                       ICQ#7615664


Tue, 13 Oct 1998 18:50:05 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
PostgreSQL v6.4 BETA2 ...
> Any arguments against getting a BETA2 out tomorrow afternoon?

None, though I've just stumbled across some config stuff which would be
nice to clean up.

It came up when I tried upgrading compilers. The new one omitted an
explicit cpp, the preprocessor. Builds failed because references to it
are hardcoded, along with paths to find it, in at least two script files
for the backend. 

It also turns out that autoconf already checks for cpp, or the
equivalent, but the result wasn't being used. So, fine, but...

autoconf concludes that "gcc -E" is equivalent to cpp on my system. And
it is, except that it needs an explicit bare "-" argument to try reading
from a pipe, which is how cpp was being used. I can test for "gcc" being
in the command, and add the argument, _or_ can change the scripts to
write a temporary file instead (they already write some temp files).

Comments? Suggestions??

                    - Tom

Oh, I'm probably going to revert back to the compiler package which
includes cpp...

Wed, 14 Oct 1998 01:33:45 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
I will be posting a configure.in tonight with further clean ups to the TCL/TK 
configuration.  TCL/TK compile information will now be obtained from the 
tclConfig.sh and tkConfig.sh, without having to have a list of different 
versions of TCL and TK to search for.

Two item I would like to bring up for discussion is:

1.  Currently TCL/TK support is disabled if TCL is present, but TK is not. This
    is not a good thing because the PL/tcl language is only dependant on TCL,
    not TK.  Also pgtclsh only requires TCL.  I propose changing configure so
    that TCL and TK support are seperate and the TCL dependant parts of the
    postgreSQL distribution will still build even if TK is not present.

2.  There is currently duplicate Makefile.tcldefs.  I propose create a
    Makefile.tcldefs and Makefile.tkdefs at the same directory level as
    Makefile.global and have any Makefile that needs them include them from
    that location.  This would then become the 'standard' for compiling TCL
    and TK based packages in the postgreSQL distribution.

Any comments and/or concerns?
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Tue, 13 Oct 1998 22:11:15 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
> I will be posting a configure.in tonight with further clean ups to the TCL/TK 
> configuration.  TCL/TK compile information will now be obtained from the 
> tclConfig.sh and tkConfig.sh, without having to have a list of different 
> versions of TCL and TK to search for.
> 
> Two item I would like to bring up for discussion is:
> 
> 1.  Currently TCL/TK support is disabled if TCL is present, but TK is not. This
>     is not a good thing because the PL/tcl language is only dependant on TCL,
>     not TK.  Also pgtclsh only requires TCL.  I propose changing configure so
>     that TCL and TK support are seperate and the TCL dependant parts of the
>     postgreSQL distribution will still build even if TK is not present.
> 
> 2.  There is currently duplicate Makefile.tcldefs.  I propose create a
>     Makefile.tcldefs and Makefile.tkdefs at the same directory level as
>     Makefile.global and have any Makefile that needs them include them from
>     that location.  This would then become the 'standard' for compiling TCL
>     and TK based packages in the postgreSQL distribution.
> 
> Any comments and/or concerns?

Be aware I removed the TCL_LIB, ... stuff from configure.in this
morning.  That was the old stuff, and your new stuff made it
unnecessary.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Tue, 13 Oct 1998 22:43:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> autoconf concludes that "gcc -E" is equivalent to cpp on my system. And
> it is, except that it needs an explicit bare "-" argument to try reading
> from a pipe, which is how cpp was being used. I can test for "gcc" being
> in the command, and add the argument, _or_ can change the scripts to
> write a temporary file instead (they already write some temp files).

Add the following to configure.in after AC_PROG_CPP and use the resultant
flag from CPPSTDIN: (either nothing or -)

--- cut here ---
AC_DEFUN(AC_TRY_CPPSTDIN,
[AC_REQUIRE_CPP()dnl
cat > conftest.$ac_ext <<EOF
[#]line __oline__ "configure"
#include "confdefs.h"
[$1]
EOF
ac_try="$ac_cpp $CPPSTDIN <conftest.$ac_ext >/dev/null 2>conftest.out"
AC_TRY_EVAL(ac_try)
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
  ifelse([$2], , :, [rm -rf conftest*
  $2])
else
  echo "$ac_err" >&AC_FD_CC
  echo "configure: failed program was:" >&AC_FD_CC
  cat conftest.$ac_ext >&AC_FD_CC
ifelse([$3], , , [  rm -rf conftest*
  $3
])dnl
fi
rm -f conftest*])

AC_MSG_CHECKING(how to use cpp with stdin)
if test -z "$CPPSTDIN"; then
AC_CACHE_VAL(ac_cv_cpp_stdin,
[  CPPSTDIN=""
  AC_TRY_CPPSTDIN([#include <assert.h>
Syntax Error], , CPPSTDIN="-")
  ac_cv_cpp_stdin="$CPPSTDIN"])
  CPPSTDIN="$ac_cv_cpp_stdin"
else
  ac_cv_cpp_stdin="$CPPSTDIN"
fi
AC_MSG_RESULT($CPP $CPPSTDIN)
AC_SUBST(CPPSTDIN)
--- cut here ---

Taral

P.S. Yes, do use the DEFUN just in case we want to add more broken variants
later :)


Tue, 13 Oct 1998 21:56:39 -0500
"Taral" <taral@mail.utexas.edu>
RE: [HACKERS] PostgreSQL v6.4 BETA2 ...
On Tue, 13 Oct 1998, Billy G. Allie wrote:

> I will be posting a configure.in tonight with further clean ups to the TCL/TK 
> configuration.  TCL/TK compile information will now be obtained from the 
> tclConfig.sh and tkConfig.sh, without having to have a list of different 
> versions of TCL and TK to search for.
> 
> Two item I would like to bring up for discussion is:
> 
> 1.  Currently TCL/TK support is disabled if TCL is present, but TK is not. This
>     is not a good thing because the PL/tcl language is only dependant on TCL,
>     not TK.  Also pgtclsh only requires TCL.  I propose changing configure so
>     that TCL and TK support are seperate and the TCL dependant parts of the
>     postgreSQL distribution will still build even if TK is not present.
> 
> 2.  There is currently duplicate Makefile.tcldefs.  I propose create a
>     Makefile.tcldefs and Makefile.tkdefs at the same directory level as
>     Makefile.global and have any Makefile that needs them include them from
>     that location.  This would then become the 'standard' for compiling TCL
>     and TK based packages in the postgreSQL distribution.
> 
> Any comments and/or concerns?
> -- 

	These changes sound great for post-v6.4...

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org                    
scrappy@{postgresql|isc}.org                       ICQ#7615664


Tue, 13 Oct 1998 23:18:32 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
>
>
> I just built and regression tested the current source tree on both Solaris
> x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> smooth...
>
> Any arguments against getting a BETA2 out tomorrow afternoon?

    Have  a crashing backend after a huge transaction on the next
    insert into a table with indices. Crash is  reproducable  and
    seems to be due to a corrupted index file.

    Recompiling with COPT=-g now...

>
> Marc G. Fournier                               scrappy@hub.org
> Systems Administrator @ hub.org
> scrappy@{postgresql|isc}.org                       ICQ#7615664
>
>
>


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Wed, 14 Oct 1998 09:51:36 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
That was me:
>
> >
> >
> > I just built and regression tested the current source tree on both Solaris
> > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > smooth...
> >
> > Any arguments against getting a BETA2 out tomorrow afternoon?
>
>     Have  a crashing backend after a huge transaction on the next
>     insert into a table with indices. Crash is  reproducable  and
>     seems to be due to a corrupted index file.
>
>     Recompiling with COPT=-g now...
>

    Harrr  -  using  text_ops  on  an  int4 field in CREATE INDEX
    doesn't make much sense.

    Bruce, please add 6.5 TODO:

    Parser must check on CREATE INDEX that the opcdeftype of  the
    used  operator  class is compatible with the indexed field or
    the index functions return type.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Wed, 14 Oct 1998 16:42:41 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
   I will be posting a configure.in tonight with further clean ups to the TCL/TK 
   configuration.  TCL/TK compile information will now be obtained from the 
   tclConfig.sh and tkConfig.sh, without having to have a list of different 
   versions of TCL and TK to search for.

These ideas sound great, but I don't understand one thing.

How do you locate the *Config.sh scripts without looking in a bunch of
directories until you find them?

Unless there is a general means of finding these which 1) doesn't
involve checking directories associated with different versions of
tcl/tk, and 2) does allow for the possibility that tcl/tk may not be
installed in a particular filesystem (/usr/local, for example), I
strongly recommend keeping the part of configure that searches for the
location of tcl/tk.  Perhaps we don't need to store the location of
include/library files based on the configure script, but I think we do
need to use essentially the same mechanism to find the *Config.sh
scripts.

Cheers,
Brook

Wed, 14 Oct 1998 08:44:53 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
>    [...]  TCL/TK compile information will now be obtained from the 
>    tclConfig.sh and tkConfig.sh, without having to have a list of different 
>    versions of TCL and TK to search for.
> 
> These ideas sound great, but I don't understand one thing.
> 
> How do you locate the *Config.sh scripts without looking in a bunch of
> directories until you find them?
> 
> Unless there is a general means of finding these which 1) doesn't
> involve checking directories associated with different versions of
> tcl/tk, and 2) does allow for the possibility that tcl/tk may not be
> installed in a particular filesystem (/usr/local, for example), I
> strongly recommend keeping the part of configure that searches for the
> location of tcl/tk.  Perhaps we don't need to store the location of
> include/library files based on the configure script, but I think we do
> need to use essentially the same mechanism to find the *Config.sh
> scripts.

I wasn't clear enough in my explaination.  I still search directories for the
*Config.sh files, but I generalized it so that a list of TCL and TK versions do not have to be maintained.  Here is the segment of code that performs the search for tclConfig.sh:

    library_dirs="$LIBRARY_DIRS /usr/lib"
    TCL_CONFIG_SH=
    for dir in $library_dirs; do
        if test -d "$dir" -a -r "$dir/tclConfig.sh"; then
            TCL_CONFIG_SH=$dir/tclConfig.sh
            break
        fi
        for tcl_dir in $dir/tcl[0-9]*.[0-9]*
        do
            if test -d "$tcl_dir" -a -r "$tcl_dir/tclConfig.sh"
            then
                TCL_CONFIG_SH=$tcl_dir/tclConfig.sh
                break 2
            fi
        done
    done

-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Wed, 14 Oct 1998 11:26:47 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
   I wasn't clear enough in my explaination.  I still search
   directories for the *Config.sh files, but I generalized it so that
   a list of TCL and TK versions do not have to be maintained.  

OK.  That clears things up, now.  But ...

   Here is the segment of code that performs the search for
   tclConfig.sh:

	   for tcl_dir in $dir/tcl[0-9]*.[0-9]*
	   do
	   ...
	   done

I think that this will fail by finding the LOWER version of tcl
before a higher version.  For example, if I have both 7.6 and 8.0
installed, won't this find 7.6 first?

Might there not be installations with an old version lying around?

Should the script be enhanced to at least report on ALL versions
found?

Should the script simply assign for each version found, rather than
breaking out of the loop?  That might have a better chance at catching
the highest version; although, it doesn't won't order 8.9 and 8.10
correctly.

Cheers,
Brook

Wed, 14 Oct 1998 10:43:57 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> 
>     Harrr  -  using  text_ops  on  an  int4 field in CREATE INDEX
>     doesn't make much sense.
> 
>     Bruce, please add 6.5 TODO:
> 
>     Parser must check on CREATE INDEX that the opcdeftype of  the
>     used  operator  class is compatible with the indexed field or
>     the index functions return type.

But, we don't require ops* anymore.  Should we prevent people from using
whatever ops they want?


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 14 Oct 1998 13:01:32 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> I think that this will fail by finding the LOWER version of tcl
> before a higher version.  For example, if I have both 7.6 and 8.0
> installed, won't this find 7.6 first?

Sorry, I've lost track of the discussion. Is it the case that people
know that pgtcl does not install at the moment? On my machine the
installation procedure has trouble finding one of the shell files under
discussion...

                 - Tom

Wed, 14 Oct 1998 17:59:41 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
On Wed, 14 Oct 1998, Jan Wieck wrote:

> >
> >
> > I just built and regression tested the current source tree on both Solaris
> > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > smooth...
> >
> > Any arguments against getting a BETA2 out tomorrow afternoon?
> 
>     Have  a crashing backend after a huge transaction on the next
>     insert into a table with indices. Crash is  reproducable  and
>     seems to be due to a corrupted index file.
> 
>     Recompiling with COPT=-g now...

	I saw Bruce's last on this...will wait until you guys have this
sorted out before I build the snapshot...

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org                    
scrappy@{postgresql|isc}.org                       ICQ#7615664


Wed, 14 Oct 1998 15:29:03 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> 
> On Wed, 14 Oct 1998, Jan Wieck wrote:
> 
> > >
> > >
> > > I just built and regression tested the current source tree on both Solaris
> > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > > smooth...
> > >
> > > Any arguments against getting a BETA2 out tomorrow afternoon?
> > 
> >     Have  a crashing backend after a huge transaction on the next
> >     insert into a table with indices. Crash is  reproducable  and
> >     seems to be due to a corrupted index file.
> > 
> >     Recompiling with COPT=-g now...
> 
> 	I saw Bruce's last on this...will wait until you guys have this
> sorted out before I build the snapshot...
> 

    Was my fault - not a bug.


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


Wed, 14 Oct 1998 23:06:19 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> > I think that this will fail by finding the LOWER version of tcl
> > before a higher version.  For example, if I have both 7.6 and 8.0
> > installed, won't this find 7.6 first?
>
> Sorry, I've lost track of the discussion. Is it the case that people
> know that pgtcl does not install at the moment? On my machine the
> installation procedure has trouble finding one of the shell files under
> discussion...
>
Can you provide more details, such as the error messages generated by make?
--
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 

Wed, 14 Oct 1998 17:33:49 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
> > I think that this will fail by finding the LOWER version of tcl
> > before a higher version.  For example, if I have both 7.6 and 8.0
> > installed, won't this find 7.6 first?
> 
> Sorry, I've lost track of the discussion. Is it the case that people
> know that pgtcl does not install at the moment? On my machine the
> installation procedure has trouble finding one of the shell files under
> discussion...

This is news to me.  The current code looks for tclConfig.sh and
tkConfig.sh in the various standard directories.  In my case, they are
in /usr/contrib/lib.  Can you add the directory that has those file to
your search path include dirs.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 14 Oct 1998 19:37:11 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> On Wed, 14 Oct 1998, Jan Wieck wrote:
> 
> > >
> > >
> > > I just built and regression tested the current source tree on both Solaris
> > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > > smooth...
> > >
> > > Any arguments against getting a BETA2 out tomorrow afternoon?
> > 
> >     Have  a crashing backend after a huge transaction on the next
> >     insert into a table with indices. Crash is  reproducable  and
> >     seems to be due to a corrupted index file.
> > 
> >     Recompiling with COPT=-g now...
> 
> 	I saw Bruce's last on this...will wait until you guys have this
> sorted out before I build the snapshot...

Fixed.  He had the wrote ops_ on the index.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 14 Oct 1998 19:39:40 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
-----BEGIN PGP SIGNED MESSAGE-----


    library_dirs="$LIBRARY_DIRS /usr/lib"
    TCL_CONFIG_SH=
    for dir in $library_dirs; do
       [...]
    done

If you can assume that Tcl is installed and the version the user wants
is first in their path, you should be able to limit this to

    library_dirs=`echo 'puts $auto_path' | tclsh`

roland

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNiVfs+oW38lmvDvNAQFpPgP9Gsk515V66r0BHUk9hIE8atCyxu08QIpo
kRWGLd3gO5vs04Y56OrNAwCZuddfr1lx+S01MP6G5HKdHWQ9z1mDGixODYrdW9K2
39HT3OHJ9YEzgoQV77m1Ef9OPmLpuboXMg1iEd4+Wv/PJrTvVVmLHCD98wMjgpgF
BenOPn5wV0w=
=NiLZ
-----END PGP SIGNATURE-----
-- 
Roland B. Roberts, PhD                  Custom Software Solutions
roberts@panix.com                           101 West 15th St #4NN
                                               New York, NY 10011


14 Oct 1998 22:36:39 -0400
Roland Roberts <roberts@panix.com>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> I think that this will fail by finding the LOWER version of tcl
> before a higher version.  For example, if I have both 7.6 and 8.0
> installed, won't this find 7.6 first?
> 
> Might there not be installations with an old version lying around?
> 
> Should the script be enhanced to at least report on ALL versions
> found?
> 
> Should the script simply assign for each version found, rather than
> breaking out of the loop?  That might have a better chance at catching
> the highest version; although, it doesn't won't order 8.9 and 8.10
> correctly.

Actually, I've looked at the configure for TCL and concluded came to the 
following conclusions:

1.  By default, the *Config.sh files go in the same directory as the library
    files (default: /usr/local/lib).

2.  If you built more than 1 version of TCL/TK, the *Config.sh will reflect
    the last version built unless you override the default location of the
    libraries.

3.  If you more than one version of TCL/TK and want to use a specific version,
    you need to tell configure where the *Config.sh file you want to use are
    with the --with-libs or --with-library option.

Bearing these points in mind, I will be removing the code that looks in tclX.Y 
(where X.Y is the version) and tkX.Y directories.  It will only look for 
*Config.sh files in the following directories (in the order given):

	$LIBRARY_DIRS		(set with --with-libs or --with-libraries)
	/usr/local/lib
	/usr/contrib/lib
	/opt/lib
	/usr/lib

This method will make searching for various versions TCL/TK unnecessary while 
still being able to find the correct TCL/TK in most cases.
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Thu, 15 Oct 1998 00:46:18 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
>     library_dirs="$LIBRARY_DIRS /usr/lib"
>     TCL_CONFIG_SH=
>     for dir in $library_dirs; do
>        [...]
>     done
> 
> If you can assume that Tcl is installed and the version the user wants
> is first in their path, you should be able to limit this to
> 
>     library_dirs=`echo 'puts $auto_path' | tclsh`
> 

This is one of those cases where you sit back and think "Now why didn't I think of that!"

The only thing I would add is to allow $LIBRARY_DIR to be searched first to allow an alternate version of TCL/TK to be specified.  Also, I would add a check to see if tclsh is in the path.

Can anyone think of a good reason not to use this method?
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Thu, 15 Oct 1998 01:00:15 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ... 
> Actually, I've looked at the configure for TCL and concluded came to the 
> following conclusions:
> 
> 1.  By default, the *Config.sh files go in the same directory as the library
>     files (default: /usr/local/lib).
> 
> 2.  If you built more than 1 version of TCL/TK, the *Config.sh will reflect
>     the last version built unless you override the default location of the
>     libraries.
> 
> 3.  If you more than one version of TCL/TK and want to use a specific version,
>     you need to tell configure where the *Config.sh file you want to use are
>     with the --with-libs or --with-library option.
> 
> Bearing these points in mind, I will be removing the code that looks in tclX.Y 
> (where X.Y is the version) and tkX.Y directories.  It will only look for 
> *Config.sh files in the following directories (in the order given):


FYI, I may have already done that in configure.in.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 15 Oct 1998 01:49:37 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...
> > Sorry, I've lost track of the discussion. Is it the case that people
> > know that pgtcl does not install at the moment? On my machine the
> > installation procedure has trouble finding one of the shell files 
> > under discussion...
> Can you provide more details, such as the error messages generated by 
> make?

Sorry, false alarm. I had seen it fail recently, but it is working great
now.

                      - Tom

Thu, 15 Oct 1998 14:19:31 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] PostgreSQL v6.4 BETA2 ...