@@ -94,35 +94,90 @@ Freezing Tkinter programs
9494-------------------------
9595
9696Unfortunately, it is currently not possible to freeze programs that
97- use Tkinter. It *seems* to work, but when you ship the frozen program
98- to a site without a Tcl/Tk installation, it will fail with a complaint
99- about missing Tcl/Tk initialization files.
100-
101- A workaround would be possible, in which the Tcl/Tk library files are
97+ use Tkinter without a Tcl/Tk installation. The best way to ship a
98+ frozen Tkinter program is to decide in advance where you are going
99+ to place the Tcl and Tk library files in the distributed setup, and
100+ then declare these directories in your frozen Python program using
101+ the TCL_LIBRARY, TK_LIBRARY and TIX_LIBRARY environment variables.
102+
103+ For example, assume you will ship your frozen program in the directory
104+ <root>/bin/windows-x86 and will place your Tcl library files
105+ in <root>/lib/tcl8.2 and your Tk library files in <root>/lib/tk8.2. Then
106+ placing the following lines in your frozen Python script before importing
107+ Tkinter or Tix would set the environment correctly for Tcl/Tk/Tix:
108+
109+ import os
110+ import os.path
111+ RootDir = os.path.dirname(os.path.dirname(os.getcwd()))
112+
113+ import sys
114+ if sys.platform == "win32":
115+ sys.path = ['', '..\\..\\lib\\python-2.0']
116+ os.environ['TCL_LIBRARY'] = RootDir + '\\lib\\tcl8.2'
117+ os.environ['TK_LIBRARY'] = RootDir + '\\lib\\tk8.2'
118+ os.environ['TIX_LIBRARY'] = RootDir + '\\lib\\tix8.1'
119+ elif sys.platform == "linux2":
120+ sys.path = ['', '../../lib/python-2.0']
121+ os.environ['TCL_LIBRARY'] = RootDir + '/lib/tcl8.2'
122+ os.environ['TK_LIBRARY'] = RootDir + '/lib/tk8.2'
123+ os.environ['TIX_LIBRARY'] = RootDir + '/lib/tix8.1'
124+ elif sys.platform == "solaris":
125+ sys.path = ['', '../../lib/python-2.0']
126+ os.environ['TCL_LIBRARY'] = RootDir + '/lib/tcl8.2'
127+ os.environ['TK_LIBRARY'] = RootDir + '/lib/tk8.2'
128+ os.environ['TIX_LIBRARY'] = RootDir + '/lib/tix8.1'
129+
130+ This also adds <root>/lib/python-2.0 to your Python path
131+ for any Python files such as _tkinter.pyd you may need.
132+
133+ Note that the dynamic libraries (such as tcl82.dll tk82.dll python20.dll
134+ under Windows, or libtcl8.2.so and libtcl8.2.so under Unix) are required
135+ at program load time, and are searched by the operating system loader
136+ before Python can be started. Under Windows, the environment
137+ variable PATH is consulted, and under Unix, it may be the
138+ the environment variable LD_LIBRARY_PATH and/or the system
139+ shared library cache (ld.so). An additional preferred directory for
140+ finding the dynamic libraries is built into the .dll or .so files at
141+ compile time - see the LIB_RUNTIME_DIR variable in the Tcl makefile.
142+ The OS must find the dynamic libraries or your frozen program won't start.
143+ Usually I make sure that the .so or .dll files are in the same directory
144+ as the executable, but this may not be foolproof.
145+
146+ A workaround to installing your Tcl library files with your frozen
147+ executable would be possible, in which the Tcl/Tk library files are
102148incorporated in a frozen Python module as string literals and written
103149to a temporary location when the program runs; this is currently left
104- as an exercise for the reader. (If you implement this, please post to
105- the Python newsgroup!)
150+ as an exercise for the reader. An easier approach is to freeze the
151+ Tcl/Tk/Tix code into the dynamic libraries using the Tcl ET code,
152+ or the Tix Stand-Alone-Module code. Of course, you can also simply
153+ require that Tcl/Tk is required on the target installation, but be
154+ careful that the version corresponds.
106155
107- Of course, you can also simply require that Tcl/Tk is required on the
108- target installation.
156+ There are some caveats using frozen Tkinter applications:
157+ Under Windows if you use the -s windows option, writing
158+ to stdout or stderr is an error.
159+ The Tcl [info nameofexecutable] will be set to where the
160+ program was frozen, not where it is run from.
161+ The global variables argc and argv do not exist.
109162
110163
111- A warning against shared library modules
112- ----------------------------------------
164+ A warning about shared library modules
165+ --------------------------------------
113166
114- When your Python installation uses shared library modules, these will
115- not be incorporated in the frozen program. Again, the frozen program
116- will work when you test it, but it won't work when you ship it to a
117- site without a Python installation.
167+ When your Python installation uses shared library modules such as
168+ _tkinter.pyd, these will not be incorporated in the frozen program.
169+ Again, the frozen program will work when you test it, but it won't
170+ work when you ship it to a site without a Python installation.
118171
119172Freeze prints a warning when this is the case at the end of the
120173freezing process:
121174
122175 Warning: unknown modules remain: ...
123176
124177When this occurs, the best thing to do is usually to rebuild Python
125- using static linking only.
178+ using static linking only. Or use the approach described in the previous
179+ section to declare a library path using sys.path, and place the modules
180+ such as _tkinter.pyd there.
126181
127182
128183Troubleshooting
@@ -164,10 +219,78 @@ winmakemakefile.py (e.g., if you are using the 4.2 compiler, the
164219python20.lib file is generated in the subdirectory vc40 of the Python
165220source tree).
166221
167- You can freeze programs that use Tkinter, but Tcl/Tk must be installed
168- on the target system.
169-
170222It is possible to create frozen programs that don't have a console
171- window, by specifying the option '-s windows'.
223+ window, by specifying the option '-s windows'. See the Usage below.
224+
225+ Usage
226+ -----
227+
228+ Here is a list of all of the options (taken from freeze.__doc__):
229+
230+ usage: freeze [options...] script [module]...
231+
232+ Options:
233+ -p prefix: This is the prefix used when you ran ``make install''
234+ in the Python build directory.
235+ (If you never ran this, freeze won't work.)
236+ The default is whatever sys.prefix evaluates to.
237+ It can also be the top directory of the Python source
238+ tree; then -P must point to the build tree.
239+
240+ -P exec_prefix: Like -p but this is the 'exec_prefix', used to
241+ install objects etc. The default is whatever sys.exec_prefix
242+ evaluates to, or the -p argument if given.
243+ If -p points to the Python source tree, -P must point
244+ to the build tree, if different.
245+
246+ -e extension: A directory containing additional .o files that
247+ may be used to resolve modules. This directory
248+ should also have a Setup file describing the .o files.
249+ On Windows, the name of a .INI file describing one
250+ or more extensions is passed.
251+ More than one -e option may be given.
252+
253+ -o dir: Directory where the output files are created; default '.'.
254+
255+ -m: Additional arguments are module names instead of filenames.
256+
257+ -a package=dir: Additional directories to be added to the package's
258+ __path__. Used to simulate directories added by the
259+ package at runtime (eg, by OpenGL and win32com).
260+ More than one -a option may be given for each package.
261+
262+ -l file: Pass the file to the linker (windows only)
263+
264+ -d: Debugging mode for the module finder.
265+
266+ -q: Make the module finder totally quiet.
267+
268+ -h: Print this help message.
269+
270+ -x module Exclude the specified module.
271+
272+ -i filename: Include a file with additional command line options. Used
273+ to prevent command lines growing beyond the capabilities of
274+ the shell/OS. All arguments specified in filename
275+ are read and the -i option replaced with the parsed
276+ params (note - quoting args in this file is NOT supported)
277+
278+ -s subsystem: Specify the subsystem (For Windows only.);
279+ 'console' (default), 'windows', 'service' or 'com_dll'
280+
281+ -w: Toggle Windows (NT or 95) behavior.
282+ (For debugging only -- on a win32 platform, win32 behavior
283+ is automatic.)
284+
285+ Arguments:
286+
287+ script: The Python script to be executed by the resulting binary.
288+
289+ module ...: Additional Python modules (referenced by pathname)
290+ that will be included in the resulting binary. These
291+ may be .py or .pyc files. If -m is specified, these are
292+ module names that are search in the path instead.
293+
294+
172295
173296--Guido van Rossum (home page: http://www.python.org/~guido/)
0 commit comments