Kaydet (Commit) dd206899 authored tarafından Jack Jansen's avatar Jack Jansen

Standalone.html is long obsolete. Added description of BuildApplication

process to freezing.html.
üst 2450a25f
...@@ -33,7 +33,7 @@ applet by double-clicking one of the datafiles. <p> ...@@ -33,7 +33,7 @@ applet by double-clicking one of the datafiles. <p>
Let's have a look at dnslookup-2.rsrc, our resource file. Dialog 512 is the Let's have a look at dnslookup-2.rsrc, our resource file. Dialog 512 is the
main window which has one button (Lookup), two labels and main window which has one button (Lookup), two labels and
two text entry areas, one of which is used for output only. The "Quit" and two text entry areas, one of which is used for output only. The "Quit"
button has disappeared, because its function is handled by a menu choice. Here's button has disappeared, because its function is handled by a menu choice. Here's
what it will look like at run time:<p> what it will look like at run time:<p>
<div align=center> <div align=center>
...@@ -127,7 +127,7 @@ applet does still depend on a lot of the python environment: the ...@@ -127,7 +127,7 @@ applet does still depend on a lot of the python environment: the
PythonCore shared library, the Python Preferences file, the python Lib PythonCore shared library, the Python Preferences file, the python Lib
folder and any other modules that the main module depends on. It is folder and any other modules that the main module depends on. It is
possible to get rid of all these dependencies and create true standalone possible to get rid of all these dependencies and create true standalone
applications in Python, but this is a bit difficult. See <a href="standalone.html"> applications in Python, but this is a bit difficult. See <a href="freezing.html">
Standalone Applications in Python</a> for details. For this Standalone Applications in Python</a> for details. For this
document, by standalone we mean here that document, by standalone we mean here that
the script has the look-and-feel of an application, including the the script has the look-and-feel of an application, including the
......
...@@ -4,31 +4,57 @@ ...@@ -4,31 +4,57 @@
</HEAD> </HEAD>
<BODY> <BODY>
<H1>Creating standalone applications with Python</H1> <H1>Creating standalone applications with Python</H1>
<HR>
With the <EM>macfreeze</EM> script you can <i>freeze</i> a Python With <a href="example2.html#applet">BuildApplet</a> you can build a standalone
script: create a fullblown Macintosh application that is completely Python application that works like
self-contained. A frozen application is similar to an applet (see <a any other Mac application: you can double-click it, run it while the
href="example2.html">Example 2</a> for information on creating applets), Python interpreter is running other scripts, drop files on it, etc. It is, however,
but where an applet depends on an existing Python installation for its still dependent on the whole Python installation on your machine: the PythonCore
standard modules and interpreter core, a frozen program does not, engine, the plugin modules and the various Lib folders.<p>
because it incorporates everything in a single binary. This means you
can copy a frozen program to a machine that does not have Python In some cases you may want to create a true application, for instance because
installed and it will work, which is not true for an applet. <p> you want to send it off to people who may not have Python installed on their
machine, or because you the application is important and you do not want changes
There are two ways to create a frozen application: through the in your Python installation like new versions to influence it.
CodeWarrior development environment or without any development
environment. The former method is more versatile and may result in <H2>The easy way</H2>
smaller binaries, because you can better customize what is included in
your eventual application. The latter method builds an application by The easiest way to create an application from a Python script is simply by dropping
glueing together the various <em>.slb</em> shared libraries that come it on the <code>BuildApplication</code> applet in the main Python folder.
with a binary Python installation into a single file. This method of BuildApplication has a similar interface as BuildApplet: you drop a script on
freezing, which does not require you to spend money on a development it and it will process it, along with an optional <code>.rsrc</code> file.
environment, is unique to MacPython, incidentally, on other platforms It does ask one extra question: whether you want to build your application for
you will always need a C compiler and linker. <p> PPC macs only, 68K macs or any Mac.<P>
<h2>Common steps</h2> What BuildApplication does, however, is very different. It parses your script,
recursively looking for all modules you use, bundles the compiled code for
The two processes have a number of steps in common. When you start all these modules in PYC resources, adds the executable machine code for the
PythonCore engine, any dynamically loaded modules you use and a main program, combines
all this into a single file and adds a few preference resources (which you
can inspect with <code>EditPythonPrefs</code>, incidentally) to isolate the
new program from the existing Python installation.<P>
Usually you do not need to worry about all this, but occasionally you may have
to exercise some control over the process, for instance because your
program imports modules that don't exist (which can happen if your script
is multi-platform and those modules will never be used on the Mac). See
the section on <a href="#directives">directives</a> below for details.
If you get strange error messages about missing modules it may also be worthwhile
to run macfreeze in report mode on your program, see below.
<P>
<H2>Doing it the hard way</H2>
With the <EM>macfreeze</EM> script, for which BuildApplication is a simple
wrapper, you can go a step further and create CodeWarrior projects and
sourcefiles which can then be used to build your final application. While
BuildApplication is good enough for 90% of the use cases there are situations
where you need macfreeze itself, mainly if you want to embed your frozen Python
script into an existing C application, or when you need the extra bit of speed:
the resulting application will start up a bit quicker than one generated
with BuildApplication. <p>
When you start
<code>Mac:Tools:macfreeze:macfreeze.py</code> you are asked for the <code>Mac:Tools:macfreeze:macfreeze.py</code> you are asked for the
script file, and you can select which type of freeze to do. The first script file, and you can select which type of freeze to do. The first
time you should always choose <em>report only</em>, which will produce a time you should always choose <em>report only</em>, which will produce a
...@@ -37,6 +63,8 @@ window. Macfreeze actually parses all modules, so it may crash in the ...@@ -37,6 +63,8 @@ window. Macfreeze actually parses all modules, so it may crash in the
process. If it does try again with a higher debug value, this should process. If it does try again with a higher debug value, this should
show you where it crashes. <p> show you where it crashes. <p>
<h2><a name="directives">Directives</a></h2>
For more elaborate programs you will often see that freeze includes For more elaborate programs you will often see that freeze includes
modules you don't need (because they are for a different platform, for modules you don't need (because they are for a different platform, for
instance) or that it cannot find all your modules (because you modify instance) or that it cannot find all your modules (because you modify
...@@ -68,6 +96,9 @@ module name, in which case it is looked up through the normal method. ...@@ -68,6 +96,9 @@ module name, in which case it is looked up through the normal method.
freeze deems the module necessary it will not be included in the freeze deems the module necessary it will not be included in the
application. application.
<DT> <code>optional</code>
<DD> Include a module if it can be found, but don't complain if it can't.
</DL> </DL>
There is actually a fourth way that macfreeze can operate: it can be used There is actually a fourth way that macfreeze can operate: it can be used
...@@ -96,7 +127,7 @@ location: when you run freeze again it will regenerate the ...@@ -96,7 +127,7 @@ location: when you run freeze again it will regenerate the
<code>frozenmodules.rsrc</code> file but not the project and bundle <code>frozenmodules.rsrc</code> file but not the project and bundle
files. This is probably what you want: if you modify your python sources files. This is probably what you want: if you modify your python sources
you have to re-freeze, but you may have changed the project and bundle you have to re-freeze, but you may have changed the project and bundle
files, so you don't want to regenrate them. <p> files, so you don't want to regenerate them. <p>
An alternative is to leave the build folder where it is, but then you An alternative is to leave the build folder where it is, but then you
have to adapt the search path in the project. <p> have to adapt the search path in the project. <p>
...@@ -117,8 +148,5 @@ with the exception that it sets the <code>sys.path</code> initialization ...@@ -117,8 +148,5 @@ with the exception that it sets the <code>sys.path</code> initialization
to <code>$(APPLICATION)</code> only. This means that all modules will only to <code>$(APPLICATION)</code> only. This means that all modules will only
be looked for in PYC resources in your application. <p> be looked for in PYC resources in your application. <p>
<h2>Freezing without CodeWarrior</h2>
This does not work yet.
</BODY> </BODY>
</HTML> </HTML>
<HTML><HEAD><TITLE>Creating true standalone applications in Python</TITLE></HEAD>
<BODY>
<H1>Creating true standalone applications in Python</H1>
<HR>
<EM>NOTE</EM> This document is obsolete. See <A HREF="freezing.html">Freezing Python
scripts</A> for a more up-to-date treatise. <p>
</HR>
You can use Python to create true standalone macintosh applications: applications
that you can distribute to other people as a single file, without dependencies
on Python being installed, etc. The process is not easy, however, and at the
moment you need a source distribution (and a C development environment, CodeWarrior
most preferred). You should first familiarize yourself with the sections
<a href="building.html">building Python from source</a> and
<a href="example2.html">building applets</a>. <p>
The application we are going to build will contain a complete interpreter,
plus <code>'PYC '</code> resources for all the Python modules the program uses.
We start by creating a resource file that contains all the modules we need,
in PYC-resource form. There are two ways to do this:
<UL>
<LI> Modify the standard <code>freeze.py</code> module to print the names of
all modules used. Copy these to a single folder, run <code>compileall.py</code>
on that folder and then run <code>PackLibDir.py</code> from the scripts folder
to create the resourcefile. This has one disadvantage: freeze finds the modules
used by parsing your Python code, so modules you don't use (for instance because
they are system-dependent and not used on the mac) are also included. You
may also have problems with dynamically loaded modules. You will also have to rename
your main module to __main__.py.
<LI> Another way to find the modules used is by option-starting your script
and setting the "interactive mode after script" flag. Exercise every corner of
your program so all your modules have been imported, and when you exit your
program and get back to the interpreter use <code>findmodulefiles.findmodulefiles</code>
to get a list of all modules used. You can now use
<code>findmodulefiles.mkpycresourcefile</code> to create your resourcefile.
</UL>
Next we create the application project. Copy the <code>PythonStandalone.prj</code>
project, replace <code>macapplication.c</code> by <code>macapplet.c</code> and
replace <code>bundle.rsrc</code> by <code>appletbundle.rsrc</code>. Also
add the PYC resource file you made in the previous step and any other resource
files you need. Set the target output file names (for all three of ppc/68k/fat).
Build your application. <p>
Finally we have to give the application the right <code>sys.path</code> initialisation.
We do this by dropping the application on <code>EditPythonPrefs</code> and removing
all path components replacing them with a single <code>$(APPLICATION)</code>. You
may have to use ResEdit after this step to remove an "alis" resource from your application,
I am not sure why this is sometimes created. <p>
If you want to get fancy you may be able to make your application smaller by removing
all unused builtin modules. If you used the findmodulefiles method above to find
your modules you can start a standalone interpreter and use
<code>findmodulefiles.findunusedbuiltins</code> to get the names of all builtin
modules your program doesn't use. You can then create a private copy of
<code>config.c</code> from which you remove all unused modules.
</BODY></HTML>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment