Re: [PATCHES] TCL/TK configuration clean-up patches

From: Brook Milligan <brook(at)trillium(dot)NMSU(dot)Edu>
To: Bill(dot)Allie(at)mug(dot)org
Cc: hackers(at)postgreSQL(dot)org, patches(at)postgreSQL(dot)org, maillist(at)candle(dot)pha(dot)pa(dot)us
Subject: Re: [PATCHES] TCL/TK configuration clean-up patches
Date: 1998-10-15 14:48:45
Message-ID: 199810151448.IAA13157@trillium.nmsu.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

1. Removed unnecessary code relating to TCL/TK configuration from configure.

Generally a good idea, but what is unnecessary depends on perspective.
See below.

2. Change TCL/TK enabling to be dependant on the existance of an executable
tclsh (locatable via $PATH) and the existance of tclConfig.sh and
tkConfig.sh.

What if the executable is not named tclsh? This is not just idle
speculation, because of the incompatibilities between different tcl
versions. There is real reason to maintain multiple versions if tcl
applications require the features of one version that are not in
another. In such cases it is natural to name the executable tclsh7.6
or tclsh8.0 or some such thing in order to distinguish them.

This really is the same problem as looking for the include/library
directories only now you are looking for (perhaps) versioned
executables.

It seems to me that the following might be a better solution:

- new configure argument to set TCL variable
--with-tcl=tclsh8.0 [ with default = tclsh ]

- USE_TCL disabled if the named tcl is not found

- TclConfig.sh found via 'echo "puts $auto_path" | ${TCL}'

- use TclConfig.sh to generate Makefile.tcl

This would give full flexibility to specify the tcl executable while
maintaining a useful default. Is there any need to search the whole
library list for TclConfig.sh?

3. The directories that are searched for the *Config.sh file is determined by
the contents of $LIBRARY_DIRS (set by '--with-libs' or '--with-libraries')
and the output generated by executing 'echo "puts $auto_path" | tchsh".
[Thanks Roland!]

See above.

Note: If TK is installed in a different location the TCL, you must use the
--with-libs (or --with-libraries) option of configure to specify it's
location.

Would it make sense to have a --with-tk-lib=/usr/xxx/tk configure
option? I suggest this because the only purpose is to find the
tkConfig.sh during configuration, not to influence all linking.
Similarly, it might make sense to have --with-tcl-lib=/usr/xxx/tcl to
override the mechanism mentioned above that relies on the tcl
executable.

These ideas would lead to the following configure arguments:

--with-tcl=... specifies tcl excutable name (or path); used to
find tcl libs which are searched for tclConfig.sh

--with-tcl-lib=... specifies a list of tcl lib directories;
used to find tclConfig.sh if tcl executable unavailable

--with-tk-lib=... specifies a list of tk lib directories;
used to find tkConfig.sh

With suitable defaults for these, the behavior you are proposing could
easily be obtained, while still maintaining rather general
configuration capability.

4. Added "USE_TK" to Makefile.global which is set if TK support is available
(as determined by the existance of tkConfig.sh). USE_TK will only be set
true if USE_TCL is true, and TK support is available. This will allow
features/programs that only depend on TCL to compile and install even if
TK support is missing.

Good.

5. Modified the pgtclsh Makefile so that pgtclsh will compile and install even
if TK support is missing. pgtksh will not be built unless TK support is
available.

Good.

Be sure to modify the INSTALL document to reflect the arguments to
configure.

Cheers,
Brook

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-10-15 15:03:51 Statistics on key distribution (was: Re: order by and index path)
Previous Message Thomas G. Lockhart 1998-10-15 14:34:43 Re: [HACKERS] postmaster locking issues.