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:
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.
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.
You must add a 'package require Tk' command to your script to successfully wrap an application with Tk in a Linux environment.
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.
"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.
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 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.
kit/src/kitInit.c does not include headers for any
packages. Instead, it contains the relevant
declarations for the
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:
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
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.
Yes. The behavior will vary depending on your operating system.
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.
When installing multiple versions of the Tcl Dev Kit on Windows, the following considerations apply:
.tclextension. This association is modified to point to the version of
wishincluded in the installation package. (When you invoke a file with this extension, the file is run using the version of
wishspecified in the file association.) To manually modify this setting (and thus associate the
.tclextension with another version of
wish), modify the system's File Types setting. In Windows Explorer, select Tools | Folder Options | File Types and configure the association to point to the desired interpreter.
.tclassociation after installing a new version, uninstalling that version will not remove the
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:
The .tap files that have not undergone the conversion remain located in
tap directory under the Tcl Dev Kit installation,
TclDevKit3.x/lib/tap/ expwin.tap snack.tap
@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.
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
TCLAPP_PKGPATH to that directory.
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.
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.