Re: [PATCHES] TCL/TK configuration clean-up patches - Mailing list pgsql-hackers

From Brook Milligan
Subject Re: [PATCHES] TCL/TK configuration clean-up patches
Date
Msg-id 199810151448.IAA13157@trillium.nmsu.edu
Whole thread Raw
In response to TCL/TK configuration clean-up patches  ("Billy G. Allie" <Bill.Allie@mug.org>)
List 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

pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: [HACKERS] PostgreSQL v6.4 BETA2...
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Statistics on key distribution (was: Re: order by and index path)