**Tcl Extension Architecture** Developed by [John Ousterhout] and others in 1999. [TEA3], which seems still be a beta version [TEA2] (aka TEA2002) simplified the original TEA configuration files and added features. * documentation ** [SampleExtension] ** [http://www.tcl.tk/doc/tea/tea_tcl2k.pdf%|%The Tcl Extension Arhitecture, Brent Welch, Michael Thomas, 1999%|%] ** [http://www.tcl.tk/doc/tea/%|%dead linke to www.tcl.tk/doc/tea%|%] ** [Annotated 10 steps to success with TEA] ** [Converting your Tcl extension to TEA2] ** [TEA: a summary of trying to use it, Vince Darley] * extensions using TEA ** itcl/itk ** clX ** tktable ** Thread ** vu Versions for Mac, [Unix], and [Windows] are available. Especially for the former of these, see [Jim Ingham]'s comments in ... [Critcl]3 has a "generate TEA package" feature ---- [MAK] (9 Nov 2004) '''C++ Extensions with TEA''' I was going to submit this as a patch, but I don't have a complete and necessarily correct solution, it turns out. More on that in a moment. The template files and tests provided by TEA assume C-only extensions. A few quick and simple changes can put you on your way to using TEA for C++ extensions. First, in tcl.m4, find "AC_PROG_CC" in the TEA_SETUP_COMPILER_CC function, and add another line that says "AC_PROG_CXX" and then run autoconf to regenerate configure from configure.in. This adds the necessary tests to determine how to run the C++ compiler, whether it be called "g++" or "CC" or whatever. AC_DEFUN(TEA_SETUP_COMPILER_CC, [ ... AC_PROG_CC AC_PROG_CXX AC_PROG_CPP ... ]) Second, in Makefile.in, find the CC definition and add a CXX definition. The configure script will replace @CXX@ the way it does @CC@ so you can use $(CXX) to refer to the C++ compiler rather than the $(CC) for the C compiler. ... PACKAGE_VERSION = @PACKAGE_VERSION@ CC = @CC@ CXX = @CXX@ CFLAGS_DEFAULT = @CFLAGS_DEFAULT@ ... Third, find the definition of the variable COMPILE and remove the $(CC) at the start of it: #COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) COMPILE = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) Fourth, you'll need to add the $(CC) into the .c.o rule, and add a .cpp.o rule to call the appropriate compiler for .cpp files: .c.@OBJEXT@: $(CC) $(COMPILE) -c `@CYGPATH@ $<` -o $@ .cpp.@OBJEXT@: $(CXX) $(COMPILE) -c `@CYGPATH@ $<` -o $@ That's pretty much it, other than wrapping your extension's Init function in extern "C" {...} to prevent mangling so Tcl's load command can find it. (You don't need to wrap other functions, such as command functions, since they're provided to Tcl via pointers rather than Tcl needing to search the symbol table for them.) Now, the problem: later versions of gcc can't link C++ objects because it will try to use the wrong runtime library, and you'll get a number of unknown symbol errors (on new/delete and gxx_personality_v0 etc.) Unfortunately the command used for linking (assigned to the SHLIB_LD variable in the Makefile) either comes from tclConfig.sh, or else is re-determined (either way it looks the same to me), but either way it specifies the plain C compiler as the linker. You can get around the problem by linking to the C++ runtime library, for instance by adding "-lstdc++" to TEA_ADD_LIBS in your configure.in script, but I suspect this is GNU-specific, and thus is probably not a good to codify in the sample extension. The way TEA determines how to link shared libraries could stand a little improvement in this regard. Maybe someone more familiar with autoconf and m4 than I (who's not particularly familiar with either) can take the above information, figure out what to do about SHLIB_LD and make C++ extensions directly supported by TEA. ---- ''[Lars H], 6 Nov 2004: I've been told that TEA is a close relative (further development of?) some [GNU] build system. Could someone provide links to introductory material on that? It is my impression that the TEA docs are written with the assumption that the developer already has some knowledge of some similar system, so maybe there are some non-TEA-specific docs out there that explains the basics...'' [MAK] (9 Nov 2004) Not exactly a relative, but rather TEA uses GNU [autoconf]-generated configure scripts (i.e., rather than a relative, it is based on the GNU build systems). It provides a template configure.in (the input to [autoconf]) and Makefile.in (which the configure script uses to generate Makefile), and and some other support files such as tcl.m4, which defines the Tcl-specific tests done by the configure script. It also defines the common "generic/unix/win/mac" layout you see in extensions. For the most part, unless you need to write additional tests (e.g. determining if certain headers are present, whether or not the platform supports a particular function, etc.) the template files are pretty much "fill in the blanks" (or otherwise "replace the name 'sample' with your extension's name") and you don't have to worry about the nastiness of [m4]. ---- [Sean McKnight] posted the following information on his experiences: I posted a similar question about a month ago and got some pointers to the Minimal GNU Windows 32 environment (i.e. mingw32) from some Tcl programmers. Check out the mingw32 site for some good explanations as to how Windows DLLs work. Essentially, all I wanted to do was to create a DLL out of some basic C code that made some calls to the Tcl/Tk libraries. Note that in the instructions that follow I do not make use of the TEA specification but instead just use a single Makefile. I would have liked to stay with the TEA spec (and may do so eventually) but from my experience I have found that the TEA is somewhat incomplete at this point. I am hoping that will change at some point in future (I wonder if anyone in the Tcl core group would know what the plans for the TEA are at this point?). So here is what eventually worked: 1). I downloaded the "mingw32" enviroment for Windows and installed under WindowsNT 4.0 (also under Windows95). I also downloaded the "impdef" utility, which is used (explained below) to generate an "export list" of functions that can be called directly from the DLL. These can be found on the mingw32 site at http://www.mingw32.org. 2). My Tcl/Tk extension makes use of the Tcl C library. Under Windows, I am required to link with an import library when creating my extension DLL. The import library is created as follows: C:\TCL832\BIN> impdef tcl83.dll > tcl83.def C:\TCL832\BIN> impdef tk83.dll > tk83.def C:\TCL832\BIN> dlltool --dllname tcl83.dll --def tcl83.def \ --output-lib libtcl83.a C:\TCL832\BIN> dlltool --dllname tk83.dll --def tk83.def \ --output-lib libtk83.a 3). An export list for my Tcl extension also had to be created. Normally only the "Init" function from the extension is exported, as it is the entry point for the extension when the extension is loaded into Tcl. All I did to create the export list was echo a couple of lines into a text file: C:\MYEXT> echo EXPORTS > myext.def C:\MYEXT> echo Myext_Init >> myext.def 4). Each C source file in my extension is compiled using the "gcc" compiler from the "mingw32" installation. After all the objects are compiled, the final DLL is constructed. A snippet of the makefile is presented below: CC = gcc OBJS = myext1.o myext2.o myext3.o DLLTOOL = dlltool TCLLIBS = c:/tcl832/lib/libtcl83.a c:/tcl832/lib/libtk83.a RM = del dll: $(OBJS) $(CC) -mdll -o junk.tmp -Wl,--base-file,base.tmp $(OBJS) $(TCLLIBS) $(RM) junk.tmp $(DLLTOOL) --dllname myext.dll --base-file base.tmp --output-exp temp.exp --def myext.def $(RM) base.tmp $(CC) -mdll -o myext.dll $(OBJS) $(TCLLIBS) -Wl,temp.exp $(RM) temp.exp It seems to work, both under NT and 95 (at least for the extension that was tested, which is pretty basic). The main challenge is understanding the requirements for constructing a DLL. Check the "[mingw32]" site documentation for the dirty details. Sean ---- [tclguy] writes that, "If you have a TEA-based Makefile, with all the latest targets up-to-date, then [[to launch [gdb] usefully]] you should only need to do 'make gdb'. This will launch tclsh into gdb with the right environment that should allow you to say 'package require Receive' and get your debugging version." ---- [MSW] says: TEA doesn't pay attention to ''prefix''. If you specify "--prefix=something" TEA still insists on "exec-prefix" being the directory where tcl was found. '''THIS SUCKS'''. As a simple example, ''configure'' anything with a ''--prefix'' of ''something'', it'll try to install into ''/usr/local/tcl/'' or wherever tcl is found. Have you people not ever tried installing something as non-root???? TEA-based Makefiles thus mean breaking any locality of installed extensions. Welcome to the great wonderful world of tomorrow. '''[DGP]''' So, the complaint is that ''--prefix='' and ''--exec-prefix='' options must both be provided? It's a sensible complaint. Register it as either a bug or feature request. [LV] I've found that, at least at times, the sample, tcl, and tk distributed packages do the prefix/exec_prefix correctly. The way these are supposed to work are that man pages, tcl scripts, script demos, etc. go under prefix while binary libraries and binary .exe (a.out) commands would be installed under exec_prefix. AND, when configure goes looking for things, it should use exec_prefix and prefix as the first locations to look for the various things it needs. Not every use of TEA gets these things right, it seems. Another tip - if you hard code path names (with versions in them ) into configure, make certain these are updated each time a new version of tcl comes out. <> Glossary | Package | Porting