D 2011-05-16T04:45:45.341
L Method\sof\sOperation
U rkeene
W 3449
<p class="kitcreator_longtext">
<b>Method of Operation</b>
<i>Details:</i> The general mechanism that enables a Tclkit to operate is a small Tcl initialization routine linked statically to the core libraries needed to operate a Tcl interpreter, the Tcl VFS Layer, and a database-backed (Metakit) Virtual File System that is appended to the end of the executable.</p><p>This project brings together all of the required pieces, plus some additional pieces that were found in the original Tclkit:
<ol type="1">
<li>Tk (dynamically linked)</li>
<li>Itcl (dynamically linked)</li>
</ol>
The source code for these pieces are downloaded, compiled, and linked, and the database containing the appropriate filesystem data is created. What sets this project apart from other similar projects is that:
<ol type="1">
<li>It attempts to be modular;</li>
<li>It supports cross-compiling;</li>
<li>It downloads the source from their original repositories;</li>
<li>It allows you to specify an arbitrary version of Tcl (including CVS); and</li>
<li>It uses GNU Autoconf scripts for compiling the part of the Tclkit that brings the whole thing together (the Kitsh)</li>
</ol>
To accomplish these goals the following mechanisms are in place:
<ol type="1">
<li>The top-level "kitcreator" script; and</li>
<li>Per-project subdirectories, each containing a "build.sh" script</li>
</ol>
The top-level "kitcreator" script is very simple. Its only job is to interpret command line arguments, and call the per-project "build.sh" scripts. For the "tcl" project it also finds the appropriate "tclConfig.sh" (and stores this path in TCLCONFIGDIR) to enable subsequent build scripts to find the appropriate Tcl to link against.
The per-project "build.sh" scripts are entirely autonomous. They are responsible for downloading the source code for the appropriate version that will compile and link against the current version of Tcl (user requested version can be found in "TCLVERS", while the actual version must be requested from the "tclConfig.sh" script), compiling it, installing a functional copy into the per-project "inst" directory, and installing anything that needs to be in the Tclkit's VFS root into the per-project "out" directory.
The exception to this is the "kitsh" project. It is the glue that binds all the individual projects together into a single executable. Its build script does not create an "inst" or an "out" directory because it is not a library. Instead, it collects all the other project's "out" directories into a single directory (starpack.vfs), as well a static file (boot.tcl). It then compiles the source code, and then installs the Metakit database containing the VFS onto the resulting executable.
If the "mk4tcl" project fails to build (or is not requested to be built), the rest of the project will be built using zip files instead of Metakit databases.
To create the storage database, one of two Tclkits is used (tried in this order):
<ol type="1">
<li>The Tclkit specified by the TCLKIT environment variable (or "tclkit" if that variable is not set) if it is functional; or</li>
<li>The built Tclkit itself</li>
</ol>
The second method will not work if the built Tclkit is not executable on the current platform (i.e., in the case of cross-compilation) and so it may be necessary to bootstrap a runnable Tclkit first.
</p>
Z 7c9cabc3a1fee212189a03015643351b