 | |
 | |
 | ||||||
contents
| 4.4 - Multi-platform binary extensions For example, if we wanted to use the Tktable extension in a Starkit that must be deployable on Windows and Linux, we would first create the lib/Tktable directory, then subdirectories for Windows and Linux and place the appropriate shared libraries into each: Tktable Then we need to replace pkgIndex.tcl with one that will load the appropriate one for the current platform: set platform [lindex $tcl_platform(os) 0] If the extension isn’t stubs-enabled and you have access to the source, you can use Critcl to generate a cross-platform package ready for inclusion in a Starkit. Tclkit is the platform specific part of the application, and the Starkit the cross-platform part. Including libraries for multiple platforms is one way of preserving this distinction but this can become impractical if there are several platforms, large extensions or a large number of extensions. One alternative approach is to deploy using a platform specific Starkit (i.e. a Starkit with only the libraries for a particular platform). This reduces the size, but at the cost of losing the cross-platform ability. Alternatively, you could separate the application into two Starkits - a platform specific part and a cross-platform part. Using this approach is quite simple - Tclkit allows a script to source a Starkit: set platform [lindex $tcl_platform(os) 0] Then compiled extensions for Linux would be stored in a Starkit called Linux.kit, for Windows in Windows.kit, and so on. To do this we create a platform specific Starkit containing all the libraries we require for our application. In this case we’ll use Tktable and the tDOM XML engine. For example, the Linux.kit directory structure would look like the following Linux.vfs The Windows.kit directory structure would be similar. Note that we have retained the separate Linux subdirectory, since this allows us to more easily merge these separate Starkits back to one cross-platform one at a later stage. The main.tcl is quite simple - since there is no application code it just needs to invoke “starkit::startup” to set up the auto_path correctly. Finally, we need to modify the application Starkit main.tcl so that it sources the platform specific Starkit on start-up. In the following code, we assume that both Starkits are located in the same directory: package require starkit This approach of assuming that the Starkits are in the same location removes the need for complicated schemes to locate each Starkit. For example, on Windows there is no need to create registry entries to record the location of the Starkits. Installation becomes a copy - and perhaps the creation of a link or shortcut from a user’s desktop to invoke the application. This same approach of storing multiple extensions in a single Starkit has been used to implement Kitten - an experimental collection of Tcl/Tk extensions. | see also | ||||
| | | | | | |
| | |