'''Deployment''' is the work it takes to move from ''finished application'' to
''application working on the end-users desktop/server/other computer'' to
''keeping the application up to date''.
** See Also **
[Distribution Mechanisms]:
[http://wintcltk.sourceforge.net/tkwrap.html%|%Tkwrap]: from the WinTclTk project
[Building Stand Alone Executables in Unix]: with [mktclapp]
[Building Stand-Alone Tcl/Tk Applications under Mac OS X]:
[VFS]:
[Critcl builds C extensions on-the-fly]:
[MicroTcl for Tcl9]:
[Jean-Claude Wippler]:
[James Garrison]:
[Script to merge C source files]:
[COMPANY: Career Demon.com plc]:
[http://phaseit.net/claird/comp.misc/deployment.html%|%Cameron Laird's personal remarks on deployment]:
[How to compile a TCL script into an EXE program]:
[A Poor Boy does Deployment]: the ''ravings'' (;-)) of [Rohan Pall] as he struggles to solve various deployment issues. This is a stream of conciousness description to show people that this stuff of putting an application on a desktop is non-trivial.
** Deployment Goals **
* One file to distribute instead of dozens of runtime scripts, shared libraries, etc.
* Decrease probability that the user will modify application (accidentally or intentionally)
[source protection]: Hide/obfuscate the algorithm being used in application
** Issues to be considered **
* On what platforms does the application need to run?
* Will the application and all of its dependencies run on these platforms?
* Where in the end-user's environment does the application and its components reside?
* How many of the application's dependant components do you need to deploy (your own tcl/tk interpreter? extensions, stand alone additional applications, images, fonts, drivers, libraries, etc.)?
* When a bug is encountered, how do you ensure that all end-users are updated appropriately?
* When end-users' versions of an application are updated, how to you ensure that data are properly updated?
* When end-users' versions of an application are updated, how to you ensure that they can revert to a prior version (when possible)?
* How can you determine how many end-users are using the application?
* Do the end-users need to share data, and if so, how do they do this?
* Are there any resource/locking issues with multiple accesses to the application or to the data (either multiple by one person, or multiple people accessing "simultaneously")?
* What permissions are required for the application to be installed - some systems require special permissions for registry updates, system wide directories to be updated, etc.?
* What special hardware needs must be met?
* What operating system / driver patches must be in place?
* In what format should the application and its components be shipped - [Deployment file formats]?
* How do you determine an accurate picture of important information by someone reporting a problem? For instance, what version of each component being used by the application, what platform, what patches, etc.?
* How are independent packages updated?
The Wikipedia has a serious page
[http://en.wikipedia.org/wiki/Software_deployment]
on the topic.
** Tools **
[GE ICE Tcl compiler]: commercial product
[Mktclapp]: a different kind of approach; provides tools for creating your own C or C++ mainline which then invokes tcl functions.
[TOBE] ("Tcl as One Big Executable"): builds UNIX and Windows binaries
[makeself]: shell script that creates self-extracting archives for all Unix platforms having a reasonable set of commands (tail, tar, sh, etc.)
Platform x tools availability table:
[BSD] [Linux] [Mac OSX] [Solaris] [Windows]
[Tclkit] yes yes yes yes yes
[Freewrap] ? yes ? ? yes
[TclPro]* ? yes ? ? yes
[Tcl Dev Kit] ? yes ? ? yes
[Mktclapp] ? yes ? ? ?
[GE ICE] ? ? ? ? ?
[TOBE] ? yes ? ? yes
[TclWrap]** ? yes ? ? yes
[Kt2c]*** ? ? ? ? ?
** [source protection%|%Source Protection] **
See [source protection]
Not all the methods described here provide the same level of protection for
your scripts, so it is important to understand how they work and account for
that against your protection needs. Many of the wrapping solutions only embed
the same code in a binary, but that doesn't prevent others from unwrapping and
reading it. Those solutions are good for general ease of use and development,
but are best for preventing end users from tinkering with your code, as they
don't provide a high level of protection.
** Single-Executable Deployment **
Various tools exist for creating single-executable deployments:
[Tclkit]: attempt to separate the runtime environment from the application environment; results in two files to distribute. One is platform specific but application neutral. The other is platform independent, but application specific.
[cookit]: a standalone Tcl/Tk binary similar to [Tclkit] at http://www.endorser.org/cookit
[FreeWrap]: which works quite nicely
[TclApp]: proprietary, commercial, a component of [Tcl Dev Kit]
[prowrap]: open-source, free, a component of [TclPro]
[Wize - Wish Integrated Zip Executable]: yet another deployment method, along with a development environment
[wrap]: the package that started it all
[TclWrap]:
[Geek]: Oct. 2006
[tcl2c]:
[https://github.com/lawrencewoodman/tarcel%|%tarcel]: allows you to combine a number of files together to create a single tarcel file that can be run by tclsh, wish, or can be sourced into another Tcl script. In addition it allows you to easily create Tcl modules made up of several files including shared libraries.
[Thatch]: create standalone scripts, "final products", ready to be run anywhere Tcl and/or Tk is available.
[tpack]: c Create standalone scripts with attached libraries as tar archive at the end of the script, ready to run with standard Tcl/Tk installations.
[FW]: Note that the standard, officially advocated technique for bundling a Tcl
interpreter and your script (and optionally even libraries etc) into a single
executable is now [Starpack]s via [TclKit]. There's no longer a lack of a
standard on the matter. The rest of these options have become esoteric in
comparison. I believe even Tcl Dev Kit now uses Starpacks (I don't know what
has become of the original wrapping tool - maybe included as well).
Of course, Starpacks are not only usually unobfuscated (and uncompiled), but
tools are actually provided in the distro to unwrap them - so of these apps,
the ones that actually do some compilation rather than just bundling still have
a leg up on TclKit. But overall, for bundling, TclKit is now definitely the
recommendation. It's a more standard and globally accepted method than is
provided for any of the other major scripting languages.
Some work that has been done on the concept of a [starkit] allows one to build
a 2 part install - a one piece interpreter with a number of extensions built
in, and one file per application, which contains its own database. This
addresses some of the concerns from users regarding multiple stand alone
documents reproducing all of the window manager support multiple times, using
up a LOT more disk space.
*** Traditional Tcl installation ***
[Bob Techentin] wisely observes, "You might consider a 'traditional' tcl/tk
installation, complete [[with]] additional packages, as a component of your
application. Take a close look at how [TclPro] tools get installed, and you'll
see that the '[wish]' executable is actually a short shell script which sets
some environment variables (e.g., LD_LIBRARY_PATH) and then execs the binary
shell."
*** Building Scripts into Tcl ***
Simply compiling the scripts into a stand alone intepreter (adding the scripts
as a series of character strings into a simple mainline that then feeds them
into the interpreter) won't hide them or even speed things up that much. This
is is a crude but simple mechanism, but gets the job done. [VFS]-based
analaogues such as [starpack%|%starpacks] are likely preferable.
** Tclkit **
Another option is to use [Tclkit]'s [starkit] [http://www.equi4.com/scripdoc/].
In a few steps:
* get Tclkit for your platform
* get the "SDX" scripted doc utility (platform independent) from [http://www.equi4.com/pub/tk/examples/]
* create dirs "myapp.vfs/", "myapp.vfs/bin/", and "myapp.vfs/lib/"
* copy your main script to "myapp.vfs/bin/main.tcl"
* copy all packages you need as dirs inside "myapp.vfs/lib/"
* wrap it all up using "sdx fs2sd myapp" ("file system to scripted doc")
* that's it, you have a runnable "myapp"
* try it (double-click, or run "./myapp" on Unix)
[JCW]: There are ways to make "main.tcl" work in unpackaged as well as in
packaged form, which is useful for debugging. All of this is based on Tcl's
Virtual File System or [VFS] in short. All examples here
[http://www.equi4.com/pub/tk/examples/] and here
[http://www.equi4.com/pub/dok/] use this same approach, you can unpack them
(with "sdx sd2fs ...") to see how they work.
[Jeff Godfrey]: "[[W]]ith the advent of [starkit]/[starpack] technology,
deployment issues are mostly a thing of the past ..."
** Basekit **
[ActiveState]'s [Tcl Dev Kit] [TclApp] tool builds on starkit technology to
make all the above a simple point-and-click exercise. It uses a file called
[basekit] as its foundation.
----
Also be sure to check out the wondrous sample offerings at the Starkit
Distribution Archive [http://tcl.tk/starkits]
** Misc **
[LV]: What would be a good web site for someone attempting to get a handle on
these types of issues, in cases where a starkit is not an option?
<<categories>> Category Deployment | Category Glossary