| | Summary (in preamble) | :option:`description` | |
| +------------------------------------------+----------------------------------------------+ |
| | Version | :option:`version` | |
| +------------------------------------------+----------------------------------------------+ |
| | Vendor | :option:`author` and :option:`author_email`, | |
| | | or --- & :option:`maintainer` and | |
| | | :option:`maintainer_email` | |
| +------------------------------------------+----------------------------------------------+ |
n | | Copyright | :option:`licence` | |
n | | Copyright | :option:`license` | |
| +------------------------------------------+----------------------------------------------+ |
| | Url | :option:`url` | |
| +------------------------------------------+----------------------------------------------+ |
| | %description (section) | :option:`long_description` | |
| +------------------------------------------+----------------------------------------------+ |
| |
| Additionally, there are many options in :file:`.spec` files that don't have |
| corresponding options in the setup script. Most of these are handled through |
| file winds up deep in the "build tree," in a temporary directory created by |
| :command:`bdist_rpm`.) |
| |
| .. % \XXX{this isn't implemented yet---is it needed?!} |
| .. % You can also specify a custom \file{.spec} file with the |
| .. % \longprogramopt{spec-file} option; used in conjunction with |
| .. % \longprogramopt{spec-only}, this gives you an opportunity to customize |
| .. % the \file{.spec} file manually: |
n | .. % |
n | .. % |
| .. % \ begin{verbatim} |
| .. % > python setup.py bdist_rpm --spec-only |
| .. % # ...edit dist/FooBar-1.0.spec |
| .. % > python setup.py bdist_rpm --spec-file=dist/FooBar-1.0.spec |
| .. % \ end{verbatim} |
n | .. % |
n | .. % |
| .. % (Although a better way to do this is probably to override the standard |
| .. % \command{bdist\_rpm} command with one that writes whatever else you want |
| .. % to the \file{.spec} file.) |
| |
| |
| .. _creating-wininst: |
| |
| Creating Windows Installers |
| python setup.py bdist_wininst |
| |
| or the :command:`bdist` command with the :option:`--formats` option:: |
| |
| python setup.py bdist --formats=wininst |
| |
| If you have a pure module distribution (only containing pure Python modules and |
| packages), the resulting installer will be version independent and have a name |
n | like :file:`foo-1.0.win32.exe`. These installers can even be created on Unix or |
n | like :file:`foo-1.0.win32.exe`. These installers can even be created on Unix |
| Mac OS platforms. |
| platforms or Mac OS X. |
| |
| If you have a non-pure distribution, the extensions can only be created on a |
| Windows platform, and will be Python version dependent. The installer filename |
| will reflect this and now has the form :file:`foo-1.0.win32-py2.0.exe`. You |
| have to create a separate installer for every Python version you want to |
| support. |
| |
n | The installer will try to compile pure modules into bytecode after installation |
n | The installer will try to compile pure modules into :term:`bytecode` after installation |
| on the target system in normal and optimizing mode. If you don't want this to |
| happen for some reason, you can run the :command:`bdist_wininst` command with |
| the :option:`--no-target-compile` and/or the :option:`--no-target-optimize` |
| option. |
| |
| By default the installer will display the cool "Python Powered" logo when it is |
| run, but you can also supply your own bitmap which must be a Windows |
| :file:`.bmp` file with the :option:`--bitmap` option. |
| The installer will also display a large title on the desktop background window |
| when it is run, which is constructed from the name of your distribution and the |
| version number. This can be changed to another text by using the |
| :option:`--title` option. |
| |
| The installer file will be written to the "distribution directory" --- normally |
| :file:`dist/`, but customizable with the :option:`--dist-dir` option. |
| |
n | .. _cross-compile-windows: |
| |
| Cross-compiling on Windows |
| ========================== |
| |
| Starting with Python 2.6, distutils is capable of cross-compiling between |
| Windows platforms. In practice, this means that with the correct tools |
| installed, you can use a 32bit version of Windows to create 64bit extensions |
| and vice-versa. |
| |
| To build for an alternate platform, specify the :option:`--plat-name` option |
| to the build command. Valid values are currently 'win32', 'win-amd64' and |
| 'win-ia64'. For example, on a 32bit version of Windows, you could execute:: |
| |
| python setup.py build --plat-name=win-amd64 |
| |
| to build a 64bit version of your extension. The Windows Installers also |
| support this option, so the command:: |
| |
| python setup.py build --plat-name=win-amd64 bdist_wininst |
| |
| would create a 64bit installation executable on your 32bit version of Windows. |
| |
| To cross-compile, you must download the Python source code and cross-compile |
| Python itself for the platform you are targetting - it is not possible from a |
| binary installtion of Python (as the .lib etc file for other platforms are |
| not included.) In practice, this means the user of a 32 bit operating |
| system will need to use Visual Studio 2008 to open the |
| :file:`PCBuild/PCbuild.sln` solution in the Python source tree and build the |
| "x64" configuration of the 'pythoncore' project before cross-compiling |
| extensions is possible. |
| |
| Note that by default, Visual Studio 2008 does not install 64bit compilers or |
| tools. You may need to reexecute the Visual Studio setup process and select |
| these tools (using Control Panel->[Add/Remove] Programs is a convenient way to |
| check or modify your existing install.) |
| |
| .. _postinstallation-script: |
| |
| The Postinstallation script |
| --------------------------- |
| |
| Starting with Python 2.3, a postinstallation script can be specified which the |
| :option:`--install-script` option. The basename of the script must be |
| "CSIDL_FONTS" |
| |
| If the folder cannot be retrieved, :exc:`OSError` is raised. |
| |
| Which folders are available depends on the exact Windows version, and probably |
| also the configuration. For details refer to Microsoft's documentation of the |
| :cfunc:`SHGetSpecialFolderPath` function. |
| |
n | Vista User Access Control (UAC) |
| =============================== |
| |
| Starting with Python 2.6, bdist_wininst supports a :option:`--user-access-control` |
| option. The default is 'none' (meaning no UAC handling is done), and other |
| valid values are 'auto' (meaning prompt for UAC elevation if Python was |
| installed for all users) and 'force' (meaning always prompt for elevation) |
| |
| .. function:: create_shortcut(target, description, filename[, arguments[, workdir[, iconpath[, iconindex]]]]) |
| |
| This function creates a shortcut. *target* is the path to the program to be |
| started by the shortcut. *description* is the description of the shortcut. |
| *filename* is the title of the shortcut that the user will see. *arguments* |
| specifies the command line arguments, if any. *workdir* is the working directory |
| for the program. *iconpath* is the file containing the icon for the shortcut, |
| and *iconindex* is the index of the icon in the file *iconpath*. Again, for |
| details consult the Microsoft documentation for the :class:`IShellLink` |
| interface. |
t | |
| |