TEA2

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 :-)

But seriously:

To be "TEA compliant" ideally means that you use the latest TEA spec, which is part of the sample extension in cvs in the Tcl SF project. However, it essentially means that your extension will compile with 'configure ; make' on any platform (including Windows), and that these have a standard set of options and targets (like recognizing --with-tcl, --enable-threads, --enable-symbols for configure and install-libraries and install-binaries targets for make).
From [L2 ]

Q: What are the recommended tools needed to build a Tcl extension packaged using TEA2?

A:

1. The source for the extension.
2. An appropriately installed C compiler

Q: What are the recommended steps required to build a Tcl extension packaged using TEA2?

A:

1. Download and extract the source code (for the sake of this example, assume the extension is sample_tea2) into a directory.

        For the sake of the following information, assume the directory structure looks like this:
        /usr/source
                /tcl
                /tk
                /sample_tea2

1. change directory into extension directory (ex. cd sample_tea2)
2. read the README, INSTALL, or other seemingly relevant documentation, to determine whether there are dependencies that need to be met before continuing.
3. create a directory into which you plan on performing the configure, compile, and testing of the extension - let's call it sample_tea2_build

        The directory structure now looks like:
        /usr/source
                /tcl
                /tk
                /sample_tea2
                /sample_tea2_build

1. change directories into sample_tea2_build
2. Execute the extension's configure command with --help to determine whether there are specific flags you are going to need during configuration time.
3. Execute the extension's configure command with appropriate flags.
4. Once configure has successfully completed, execute the make command.
5. Execute a make test if the extension writer provides a test target, to see if the code is working as expected on your platform.
6. Execute a make install once you are ready for the extension to be installed.

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.