| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 1 | <HTML> |
| 2 | <HEAD> |
| 3 | <TITLE>Creating standalone applications with Python</TITLE> |
| 4 | </HEAD> |
| 5 | <BODY> |
| 6 | <H1>Creating standalone applications with Python</H1> |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 7 | |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 8 | With <a href="example2.html#applet">BuildApplet</a> you can build a standalone |
| 9 | Python application that works like |
| 10 | any other Mac application: you can double-click it, run it while the |
| 11 | Python interpreter is running other scripts, drop files on it, etc. It is, however, |
| 12 | still dependent on the whole Python installation on your machine: the PythonCore |
| 13 | engine, the plugin modules and the various Lib folders.<p> |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 14 | |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 15 | In some cases you may want to create a true application, for instance because |
| 16 | you want to send it off to people who may not have Python installed on their |
| 17 | machine, or because you the application is important and you do not want changes |
| 18 | in your Python installation like new versions to influence it. |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 19 | |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 20 | <H2>The easy way</H2> |
| 21 | |
| 22 | The easiest way to create an application from a Python script is simply by dropping |
| 23 | it on the <code>BuildApplication</code> applet in the main Python folder. |
| 24 | BuildApplication has a similar interface as BuildApplet: you drop a script on |
| 25 | it and it will process it, along with an optional <code>.rsrc</code> file. |
| 26 | It does ask one extra question: whether you want to build your application for |
| 27 | PPC macs only, 68K macs or any Mac.<P> |
| 28 | |
| 29 | What BuildApplication does, however, is very different. It parses your script, |
| 30 | recursively looking for all modules you use, bundles the compiled code for |
| 31 | all these modules in PYC resources, adds the executable machine code for the |
| 32 | PythonCore engine, any dynamically loaded modules you use and a main program, combines |
| 33 | all this into a single file and adds a few preference resources (which you |
| 34 | can inspect with <code>EditPythonPrefs</code>, incidentally) to isolate the |
| 35 | new program from the existing Python installation.<P> |
| 36 | |
| 37 | Usually you do not need to worry about all this, but occasionally you may have |
| 38 | to exercise some control over the process, for instance because your |
| 39 | program imports modules that don't exist (which can happen if your script |
| 40 | is multi-platform and those modules will never be used on the Mac). See |
| 41 | the section on <a href="#directives">directives</a> below for details. |
| 42 | If you get strange error messages about missing modules it may also be worthwhile |
| 43 | to run macfreeze in report mode on your program, see below. |
| 44 | <P> |
| 45 | |
| 46 | <H2>Doing it the hard way</H2> |
| 47 | |
| 48 | With the <EM>macfreeze</EM> script, for which BuildApplication is a simple |
| 49 | wrapper, you can go a step further and create CodeWarrior projects and |
| 50 | sourcefiles which can then be used to build your final application. While |
| 51 | BuildApplication is good enough for 90% of the use cases there are situations |
| 52 | where you need macfreeze itself, mainly if you want to embed your frozen Python |
| 53 | script into an existing C application, or when you need the extra bit of speed: |
| 54 | the resulting application will start up a bit quicker than one generated |
| 55 | with BuildApplication. <p> |
| 56 | |
| 57 | When you start |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 58 | <code>Mac:Tools:macfreeze:macfreeze.py</code> you are asked for the |
| 59 | script file, and you can select which type of freeze to do. The first |
| 60 | time you should always choose <em>report only</em>, which will produce a |
| 61 | listing of modules and where they are included from in the console |
| 62 | window. Macfreeze actually parses all modules, so it may crash in the |
| 63 | process. If it does try again with a higher debug value, this should |
| 64 | show you where it crashes. <p> |
| 65 | |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 66 | <h2><a name="directives">Directives</a></h2> |
| 67 | |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 68 | For more elaborate programs you will often see that freeze includes |
| 69 | modules you don't need (because they are for a different platform, for |
| 70 | instance) or that it cannot find all your modules (because you modify |
| 71 | <code>sys.path</code> early in your initialization). It is possible to |
| 72 | include directives to tell macfreeze to add items to the search path and |
| 73 | include or exclude certain modules. All your directives should be in the |
| 74 | main script file. <p> |
| 75 | |
| 76 | Directives have the following form: |
| 77 | <pre> |
| 78 | # macfreeze: command argument |
| 79 | </pre> |
| 80 | The trigger <code>macfreeze:</code> must be spelled exactly like that, |
| 81 | but the whitespace can be any combination of spaces and tabs. Macfreeze |
| 82 | understands the following directives: |
| 83 | |
| 84 | <DL> |
| 85 | <DT> <code>path</code> |
| 86 | <DD> Prepend a folder to <code>sys.path</code>. The argument is a |
| 87 | pathname, which should probably be relative (starting with a colon) and |
| 88 | is interpreted relative to the folder where the script lives. |
| 89 | |
| 90 | <DT> <code>include</code> |
| 91 | <DD> Include a module. The module can either be given by filename or by |
| 92 | module name, in which case it is looked up through the normal method. |
| 93 | |
| 94 | <DT> <code>exclude</code> |
| 95 | <DD> Exclude a module. The module must be given by modulename. Even when |
| 96 | freeze deems the module necessary it will not be included in the |
| 97 | application. |
| 98 | |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 99 | <DT> <code>optional</code> |
| 100 | <DD> Include a module if it can be found, but don't complain if it can't. |
| 101 | |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 102 | </DL> |
| 103 | |
| 104 | There is actually a fourth way that macfreeze can operate: it can be used |
| 105 | to generate only the resource file containing the compiled <code>PYC</code> |
| 106 | resources. This may be useful if you have embedded Python in your own |
| 107 | application. The resource file generated is the same as for the CodeWarrior |
| 108 | generation process. <p> |
| 109 | |
| 110 | <h2>Freezing with CodeWarrior</h2> |
| 111 | |
| 112 | To freeze with CodeWarrior you need CodeWarrior, obviously, and a full |
| 113 | source distribution of Python. You select the <em>Codewarrior source and |
| 114 | project</em> option. You specify an output folder, which is by default |
| 115 | the name of your script with <code>.py</code> removed and |
| 116 | <code>build.</code> prepended. If the output folder does not exist yet |
| 117 | it is created, and a template project file and bundle resource file are |
| 118 | deposited there. Next, a source file <code>macfreezeconfig.c</code> is |
| 119 | created which includes all builtin modules your script uses, and a |
| 120 | resource file <code>frozenmodules.rsrc</code> which contains the |
| 121 | <code>PYC</code> resources for all your Python modules. <p> |
| 122 | |
| 123 | The project expects to live in a folder one level below the Python root |
| 124 | folder, so the next thing you should do is move the build folder there. |
| 125 | It is a good idea to leave an alias with the same name in the original |
| 126 | location: when you run freeze again it will regenerate the |
| 127 | <code>frozenmodules.rsrc</code> file but not the project and bundle |
| 128 | files. This is probably what you want: if you modify your python sources |
| 129 | you have to re-freeze, but you may have changed the project and bundle |
| Jack Jansen | dd20689 | 1999-12-03 16:00:20 +0000 | [diff] [blame] | 130 | files, so you don't want to regenerate them. <p> |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 131 | |
| 132 | An alternative is to leave the build folder where it is, but then you |
| 133 | have to adapt the search path in the project. <p> |
| 134 | |
| 135 | The project is set up to include all the standard builtin modules, but |
| 136 | the CW linker is smart enough to exclude any object code that isn't |
| 137 | referenced. Still, it may be worthwhile to remove any sources for |
| 138 | modules that you are sure are not used to cut back on compilation time. |
| 139 | You may also want to examine the various resource files (for Tcl/Tk, for |
| 140 | instance): the loader has no way to know that these aren't used. <p> |
| 141 | |
| 142 | You may also need to add sourcefiles if your script uses non-standard |
| 143 | builtin modules, like anything from the <code>Extensions</code> folder. <p> |
| 144 | |
| 145 | The <code>frozenbundle.rsrc</code> resource file contains the bundle |
| 146 | information. It is almost identical to the bundle file used for applets, |
| 147 | with the exception that it sets the <code>sys.path</code> initialization |
| 148 | to <code>$(APPLICATION)</code> only. This means that all modules will only |
| 149 | be looked for in PYC resources in your application. <p> |
| 150 | |
| Jack Jansen | d969061 | 1998-06-26 15:01:52 +0000 | [diff] [blame] | 151 | </BODY> |
| 152 | </HTML> |