Tcl Extension Architecture (TEA), version 2.
TEA version 2 should now be considered obsolete. The current TEA version as of March 2005 is TEA3.2.
The directory and file structure of a TEA package is basically:
$exec_prefix / \ lib bin | | PACKAGEx.y (dependent .dll files on Windows) | pkgIndex.tcl (.so|.dll files)
The main dynamic (.so or .dll) library file gets installed in the versioned PACKAGE directory, which is OK on all platforms because it will be directly referenced with by 'load' in the pkgIndex.tcl file. Dependent DLL files on Windows must go in the bin directory (or other directory on the user's PATH) in order for them to be found.
Q: What are the steps one needs to take if one has some C and Tcl code that currently can be loaded as a Tcl extension, if they want to restructure the code to be TEA2 compliant?
A: The easiest way is to grab a copy of the sampleextension module from the Tcl CVS repository [L1 ], and edit Makefile.in and configure.in according to the instructions therein. You'll also need GNU autoconf (and GNU m4, and perhaps a few other dependencies). Run autoconf to generate a configure shell script from configure.in, and distribute it with your package.
If you're familiar with autoconf and make, you might want to write your own configure.in and Makefile.in instead -- the sampleextension Makefile imposes some requirements on the directory layout that might not match your current source setup. tcl.m4 -- the file containing the TEA autoconf macros -- is extremely well commented and fairly easy to follow. I can't say the same for the sampleextension Makefile.in, though :-(
Q: How does one determine that a package is TEA2 compliant?
A: Ask Jeff Hobbs to try building it. If it works for him, the package is compliant :-)
Q: What are the recommended tools needed to build a Tcl extension packaged using TEA2?
Q: What are the recommended steps required to build a Tcl extension packaged using TEA2?
For the sake of the following information, assume the directory structure looks like this: /usr/source /tcl /tk /sample_tea2
The directory structure now looks like: /usr/source /tcl /tk /sample_tea2 /sample_tea2_build
See also TEA.
A commonly asked question is Where can I find TEA2 documentation? The common answer is Read the files included in the sampleextension (location mentioned above). Additionally, see TIP#34 [L3 ] and TIP#78 [L4 ] .
After doing a CVS checkout of samplextension, I suspect that the common reaction to this answer would be disappointment & confusion, as from what I can see this documentation appears decidedly out of date. tea.pdf was last modified in 1999 and refers to a nonexistant tea mailinglist at scriptics.com. I can't find any documentation differentiating TEA2 from TEA. If the 'answer' above is supposed to indicate that the only real change from TEA to TEA2 was the name - this should probably be clarified. JMN
It's my understanding that there have been some changes to some of the macros as well as other practical changes to things. As to the out of date documentation, that is indeed a frustration point.
Maybe the thing that should be done is to take the TEA documentation and turn it into a TIP which if accepted makes the architecture a part of the TCT's active responsibility.
LV One thing that I wish people using the TEA2 structure would do is use the TEA2 directory tree as one of the places to look for config scripts, include files, and libraries when searching for auxilary libraries. For instance, if one were to write a Tcl extension which required libz, then not only would it be useful to look in /lib, /usr/lib, and /usr/local/lib, but also to look in $exec_prefix/lib as well. Then, if things could not be found, that's when to generate the error that the user needs to include a flag to indicate where things are located.
Also, if one is going to need to know the directory for include files as well as libraries, it would be helpful to include 3 config flags - one for the top level directory under which one can find the include files and libraries, and then one for the installation directory of the include files and one for the installation directory of the libraries. Having either the top level or the individual level allows both the traditional installation technique, as well as the non-traditional, where one may use differing locations or even have the include files under a source code management system and the shared libraries in a public directory.
LV Any chance that some additional directories could work their way into the TEA2 directory structure? For instance, how about locations where executable demos and non-man page docs (like tutorials, etc.) could be installed? For that matter, I don't see man pages mentioned above.