Tcl Dev Kit FAQ

Why does the Tcl Dev Kit installer say it cannot find the Tcl Dev Kit package?

If the Tcl Dev Kit installer generates a message that it cannot find the Tcl Dev Kit package, it is likely that the TCL_LIBRARY variable is set in your environment. (Installing the Ruby language, for example, automatically sets this variable.) This variable is unnecessary, and should be removed.

Windows 9x users can remove the variable by editing their autoexec.bat file. Reboot the system when complete.

Windows XP (or later) users can remove the variable by altering their Environment Settings:

How do I distribute programs compiled with the Tcl Dev Kit Compiler?

The Tcl Dev Kit Compiler generates bytecode representations of Tcl scripts for the purpose of obscuring and securing the code. However, compiled applications do not include a Tcl interpreter, and thus rely on an interpreter installed on the client machine.

The ActiveTcl distribution includes a tbcload library that is free to distribute, and can be used to load compiled applications. Alternatively, use TclApp to generate a compiled application that includes an interpreter and the required libraries.

Why can't my TclApp-wrapped application access wrapped files via relative paths?

A wrapped application inherits the current working directory from the shell where the application was run. Runtime support does not change the current working directory to a location inside of the wrapped application before running it. Therefore, you must use a method such as set base $starkit::topdir to specify the base path. See Path Handling in the "Converting Prowrap Projects to TclApp Projects" section of the TclApp documentation for more information.

Why are Tk commands not recognized when I wrap my application with Tk in a Linux environment?

You must add a 'package require Tk' command to your script to successfully wrap an application with Tk in a Linux environment.

What are Starkits and Starpacks?

A starkit is a single file that packages a set of Tcl scripts, platform-specific compiled code and application data. It relies on an external run-time interpreter. A starpack is a single executable file that contains both a starkit and an interpreter.

TclApp generates a starpack when a base kit is specified as a build option. Specify a base kit in the Prefix file field on the Wrapping Tab in the graphical TclApp, or using the -prefix option on the command line. See Specifying the Interpreter: Creating Starpacks and Starkits in the TclApp section for more information.

See http://www.equi4.com/191 for an Anatomy of a starkit.

How do I create a custom base kit?

"Base kits" are executable files that include an interpreter. Base kits can be included in applications generated by TclApp in order to generate a standalone, portable application (a "starpack").

The Tcl Dev Kit includes two platform-specific base kits: base-tcl* and base-tk* (which is the equivalent of base-tcl plus tk). Custom base kits can also be included in applications generated by TclApp. For example, custom base kits would be required to use old build systems which create only static libs.

Before customizing the build process to create a custom tclkit, ensure that the standard tclkit will build without errors.

Note that as the resulting applications containing your static libraries are different from the original tclkits, to avoid confusion they should not be named "tclkit". For example, ActiveState calls the binaries provided with the Tcl Dev Kit "base-kits".

For more information, see the starkit mailing list at http://www.equi4.com/277. This list is for the general discussion of starkits and tclkits.

UNIX

Jean-Claude Wippler provides instructions and a script for generating base kits on his site, located at http://www.equi4.com/218. The primary consideration for creating custom base kits is the inclusion of your own static libraries. These must be specified in the following locations:

The Tclkit Sources

The static libraries must be included in the sources of tclkit, so that the package is initialized at runtime. The relevant source file is kit/src/kitInit.c. (This file is extracted from the archive kit.tar.gz, retrieved during the kit-building process.) kit/src/kitInit.c contains slightly non-standard initialization code for a tcl core / application. However, the parts where packages are initialized are standard.

Note that kit/src/kitInit.c does not include headers for any packages. Instead, it contains the relevant extern... declarations for the package_Init functions.

The Linking Phase of Tclkit

Create a file called genkit.local in the directory where genkit is called. This file contains the following statements:

    set Z(tclsuff) <your static libraries>
    set Z(tksuff)  <your static libraries>

"your static libraries" might be something like:

    <path>/libFOO.a

...or:

    -L<path> -lfoo.

Windows

The kit.tar.gz file described in the previous section has a subdirectory called "msvc6", which provides MSVC++ workspace and project files for the creation of a tclkit on Windows.

The expected directory layout is:

 
    tclkit/msvc6/kit.dsw etc
    Dists/Tcl/...
         /Tk/...
         /Mk4tcl/...
         /Vfs/...
         /Itcl/...
         /Zlib/...
    Build/

"tclkit" is the directory provided by kit.tar.gz. The "Build" directory is for temporary files. The "Dists" directory is populated with the contents of the tar files retrieved from http://www.equi4.com/pub/tk/tars/. (On UNIX, as described above, this retrieval is done by "genkit").

The results of the build are kit.exe and kitsh.exe in the tclkit/ directory. These are incomplete executables. To complete the generation, use:

    cat kitsh.exe tclkit/runtime.kit > tclkitsh.exe
    cat kit.exe tclkit/runtime.kit > tclkit.exe

Insertion of your own libraries has to happen in tclkit/src/kitInit.c (as described in the UNIX section above), and in the link step of the MSVC project.

Can I install multiple versions of the TDK?

Yes. The behavior will vary depending on your operating system.

Unix

On Unix, install different versions of the Tcl Dev Kit in different directories. Alter the system's PATH variable to specify the bin directory of the desired installation.

Windows

When installing multiple versions of the Tcl Dev Kit on Windows, the following considerations apply:

Where are the .tap files located?

TclApp Package definition (.tap) files are reorganized in the 3.x distribution of the Tcl Dev Kit. The majority of .tap files have undergone a conversion that facilitates moving them with a package directory. These .tap files are now located under the packages they belong to, for example:

    TclDevKit3.0/lib/bwidget1.6/
      bwidget.tap

or

    TclDevKit3.1/lib/tcllib1.5/
      tcllib.tap

The .tap files that have not undergone the conversion remain located in the tap directory under the Tcl Dev Kit installation, for example:

    TclDevKit3.x/lib/tap/
      expwin.tap
      snack.tap

How does TclApp find moved packages and .tap files?

Add the @TAPDIR@ placeholder in the .tap file you want to move, and then put the .tap file in the same directory as the package file. The .tap file now moves with the package directory and TclApp can find the correct files to wrap, relative to the location of the .tap file.

How does TclApp find custom .tap files for packages not included with the Tcl Dev Kit?

There are two solutions:

1. Set the Environment Variable to the Directory

Put all your .tap files in a custom directory and set the environment variable TCLAPP_PKGPATH to that directory.

2. Set a Placeholder

In your .tap files, use the @TAPDIR@ placeholder as a reference for the package directory, and then put the .tap file in the same directory as the package files. TclApp finds the correct files to wrap, relative to the location of the .tap file.

What can cause an "Error in startup script"?

If the implentation of a package tells Tcl what version it is (e.g. 1.3.1) and the index file of that package (pkgIndex.tcl - used by Tcl to map from versions to implementations) is not consistent with the implementation (e.g. maps version 1.3 to the implementation of version 1.3.1), an error in the startup script may occur.

This can affect ActiveTcl 8.5 if it is used in conjunction with an older ActiveTcl for the packages to use. We have no hard data which old releases are problematical, and which are good. ActiveTcl 8.4.9 has at least one package with an inconsistency of this type, i.e. starkit 1.3 vs 1.3.1.

TclApp is only indirectly affected, and only TclApp. The result of its operation may fail if a Tcl 8.5 basekit was used, and packages having the inconsistency were wrapped as well. These packages may have come from older versions of ActiveTcl, or they may be packages the user of Tclapp has developed locally, i.e. company internal packages, etc.