Updated 2006-01-31 15:24:15 by escargo

What is the canonical way of configuring a Tcl installation for site specific purposes?

I think it's a well known problem: You are using a Tcl-installation which is installed from the system supplier (e.g., a Linux distro). Tcl/Tk and the libs provided are installed under /usr/lib, thus limiting the search path to /usr/lib/ and descendants. These directories will be regularly wiped out during a system upgrade. Beside this part of the installation you maintain another set of libs and packages specific for this site (so normally under /usr/local/lib). For that reason the search path has to be extended. What is the best way to manage this across updates?

  • a special package config-site, which is part of the distribution and will be evaluated during the init-process, so that during the update this package can be backed up
  • like above but not evaluated during init, but immediately after the program start
  • simply adding the code to the application
  • ...

What is your opinion?

joheid

RS: Use a self-contained Tclkit with all the needed libs built in?

joheid: agreed as optimal for smaller programs, but if you always need a bunch of libs?

schlenk: It's rather problematic to do a cross-platform solution to this, especially if Microsoft Windows gets involved. But on Linux you should follow the FHS http://www.pathname.com/fhs/. One way I found quite nice for appending to the package search path was setting the TCLLIBPATH environment variable to my local package repository. See auto_path for other options to initialize the search path.

Category Deployment