$env(TCLLIBPATH) is a Tcl list, not some platform-specific colon-separated or semi-colon separated format, of paths to prepend to $auto_path. Regardless of platform, each item in $env(TCLLIBPATH) should use / to delimit parts of a path.
set env(TCLLIBPATH) [list /opt/tcl/site-lib /users/pat/working]
$env(TCLLIBPATH) is often not set by Tcl, and is designed to be set on a case-by-case basis depending on the needs of the site or the individual user to provide Tcl with additional site-specific locations to search for packages, or to test a package without installing it.
I like to keep all my local packages separate from the ActiveTcl installation that I use as a base. So I install all additional packages to a site-lib directory and then set $env(TCLLIBPATH) to this directory path. With this in place package require XYZ searches ActiveTcl and my site-lib directory for the most recent version of XYZ.
I download a package onto my machine. The package has a README, a demo directory, a lib directory, etc. Within the lib directory I see 3 sub-directories, and within the sub-directories are the pkgIndex.tcl file, etc.
So the basic layout is:
Installation directory/ README.txt demos/ lib/ package1/ pkgIndex.tcl package2/ pkgIndex.tcl package3/ pkgIndex.tcl src/ tests/
So, what path(s) go into TCLLIBPATH? the path to the lib/, or each of the individual packages?
PT: the lib directory.
LV PT, thank you for the answer. I tried using that, and ran into my long time nemesis - Windows folders with spaces in the names. So eventually, when I have time, I need to change to using file join to set $env(TCLLIBPATH) rather than just hard coding it, so that it has some chance of working.
I ran git, then do 'cd' to be in HOME directory and then add file .bashrc with these lines:
$ cd $ cat .bashrc TCLLIBPATH=" . C:/Tcl/lib" export TCLLIBPATH $
Then at the next start of git, you will be able to use library packages from external (to git) Tcl installation (for instance Activestate Tcl).
Space character seems to be required at the beginning of $env(TCLLIBPATH): you can try the following lines on command line to experience it
$ unset TCLLIBPATH $ TCLLIBPATH=". C:/Tcl/lib" $ export TCLLIBPATH $ tclsh % package require Expect can't find package Expect % exit $ TCLLIBPATH=" . C:/Tcl/lib " $ export TCLLIBPATH $ tclsh % package require Expect 5.43.2 % exit $
APN I believe this is by design. Tclkits are intended to work without being affected by the host environment where the user may have other Tcl distributions installed.
AMG: An override would be most welcome. I'm trying to use my own bundled tclkit to run the tcllib and critcl build/install scripts in an automated overarching build script for my application, and I need to not rely on the system tclsh and Tcl libraries which may not exist. Yet, I'm also not bundling tcllib inside my bootstrap tclkit because that's a chicken-and-egg situation. The final tclkit does end up containing pieces of tcllib and packages built with the aid of critcl, but I obviously can't use it in the process of building itself. Right now, my solution is to patch critcl's build.tcl between unpacking and running it, adding a line to point auto_path to my libraries. Naturally, I'd prefer to avoid the maintenance burden imposed by digging into critcl internals, but I see no alternative at this time.