c04bcba0d6
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@43173 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
142 lines
7.0 KiB
HTML
142 lines
7.0 KiB
HTML
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
|
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
|
|
<title>Installing wxPython 2.7 from Source</title>
|
|
<link rel="stylesheet" href="default.css" type="text/css" />
|
|
</head>
|
|
<body>
|
|
<div class="document" id="installing-wxpython-2-7-from-source">
|
|
<h1 class="title">Installing wxPython 2.7 from Source</h1>
|
|
<p>This document will describe the few differences and additions to the
|
|
content in the <a class="reference" href="BUILD.html">BUILD</a> document for installing wxPython built from
|
|
source. Please follow the intstructions both in this file and in
|
|
<a class="reference" href="BUILD.html">BUILD</a> to perform this task. Where there is overlap the items
|
|
described here will take precedence for doing installations.</p>
|
|
<div class="section">
|
|
<h1><a id="installing-on-unix-like-systems-not-os-x" name="installing-on-unix-like-systems-not-os-x">Installing on Unix-like Systems (not OS X)</a></h1>
|
|
<ol class="arabic">
|
|
<li><p class="first">When building wxWidgets you need to decide if you want it to be a
|
|
private copy only accessed by wxPython, or if you would like it to
|
|
be installed in a stanard location such as /usr. Or perhaps you
|
|
already have a version of wxWidgets installed on your system (such
|
|
as from an RPM) and you want wxPython to use that version too. If
|
|
so then you'll want to ensure that the flags and options used to
|
|
build the installed version are compatible with wxPython.</p>
|
|
</li>
|
|
<li><p class="first">If you do decide to build and install your own wxWidgets then there
|
|
are a few tweaks to the configure flags described in BUILD.txt that
|
|
you will probably want to make. Instead of --enable-debug use
|
|
this configure flag:</p>
|
|
<pre class="literal-block">
|
|
--enable-optimize \
|
|
</pre>
|
|
<p>Normally I also use the following flag in order to have wxWidgets
|
|
runtime assertions turned into Python exceptions where possible.
|
|
It does add extra code to the build but probably not enough to
|
|
worry about it. However if you want to get as lean a build as
|
|
possible you can leave it out, but if your code does something bad
|
|
then instead of exceptions you'll likely get a crash:</p>
|
|
<pre class="literal-block">
|
|
--enable-debug_flag \
|
|
</pre>
|
|
<p>If you are building a private copy of wxWidgets (IOW, not installed
|
|
in a standard library location) then it can be kind of a hassle to
|
|
always have to set the LD_LIBRARY_PATH variable so wxPython can
|
|
find the wxWidgets shared libraries. You can hard code the library
|
|
path into the binaries by using the rpath option when configuring
|
|
wxWidgets. For example:</p>
|
|
<pre class="literal-block">
|
|
--enable-rpath=/opt/wx/2.7/lib \
|
|
</pre>
|
|
<p>SOLARIS NOTE: The --enable-rpath option may cause problems when
|
|
using wxGTK on Solaris when compiling wxPython as described below.
|
|
The woraround is to not use --enable-rpath flag for configure, but
|
|
in that case all wxPython applications <em>must</em> have the
|
|
LD_LIBRARY_PATH set to include $WXPREF/lib, or you can use the
|
|
'crle' program to modify the runtime linking environment. If this
|
|
is the only installation of wxGTK on the system then you can use a
|
|
system library path for prefix and not have to worry about it at
|
|
all.</p>
|
|
</li>
|
|
<li><p class="first">Build and install wxGTK as described in BUILD.txt.</p>
|
|
</li>
|
|
<li><p class="first">In addition to building wxPython as described in BUILD.txt, you can
|
|
install it to Python's site-packages dir, as well as some scripts
|
|
into the same bin dir used by Python by using this command, plus
|
|
whatever WXPORT, UNICODE, etc. settings you used for the initial
|
|
build step:</p>
|
|
<pre class="literal-block">
|
|
python2.5 setup.py install
|
|
</pre>
|
|
<p>If you would like to install to some place besides the prefix where
|
|
Python is installed, (such as to your home directory) then you can
|
|
add "--root=<path>" after the "install" command. This will use
|
|
<path> as the prefix and will install scripts to a bin subdir and
|
|
the wxPython packages to a lib subdir. To use wxPython like this
|
|
you'll need to ensure that the directory containing wxPython is
|
|
contained in the PYTHONPATH environment variable.</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
<div class="section">
|
|
<h1><a id="installing-on-os-x" name="installing-on-os-x">Installing on OS X</a></h1>
|
|
<p>Installing wxPython on OS X is nearly the same as the Unix
|
|
instructions above, except for a few small, but important details:</p>
|
|
<ol class="arabic simple">
|
|
<li>The --enable-rpath configure option is not needed since the path to
|
|
the wxWidgets dylibs will automatically be encoded into the
|
|
extension modules when they are built. If you end up moving the
|
|
wxWidgets dynlibs to some other location (such as inside the .app
|
|
bundle of your applicaiton for distribution to other users,) then
|
|
you will need to set DYLD_LIBRARY_PATH to this location so the
|
|
dylibs can be found at runtime.</li>
|
|
<li>Depending on the version of OS X Python may be installed in
|
|
different locations. On 10.2 (Jaguar) you need to download and
|
|
install MacPython-OSX-2.3 from <a class="reference" href="http://www.python.org/">http://www.python.org/</a> and the
|
|
Python Framework will then be installed in /Library/Frameworks. On
|
|
10.3 (Panther) Apple supplies the Python Framework as part of the
|
|
OS install, but it will be located in /System/Library/Frameworks
|
|
instead. However, on Panther the site-packages dir is sym-linked
|
|
to /Library/Python/2.3 so the wxPython packages will end up there,
|
|
although they will still be visible from site-packages. If you are
|
|
building distributions of wxPython to be installed on other
|
|
machines be careful to install to /Library/Python/2.3. To
|
|
complicate things further, the Jaguar version, or a custom build
|
|
you do yourself will end up in /Library/Frameworks even on
|
|
Panther...</li>
|
|
<li>You need to use pythonw at the command line or the PythonLauncher
|
|
app to run wxPython apps, otherwise the app will not be able to
|
|
fully use the GUI display.</li>
|
|
</ol>
|
|
</div>
|
|
<div class="section">
|
|
<h1><a id="installing-on-windows" name="installing-on-windows">Installing on Windows</a></h1>
|
|
<ol class="arabic">
|
|
<li><p class="first">Build wxWidgets and wxPython as described in BUILD.txt. If you
|
|
would rather have a version without the code that turns runtime
|
|
assertions into Python exceptions, then use "release" instead of
|
|
"hybrid" when building wxWidgets and add "FINAL=1" to the setup.py
|
|
command line.</p>
|
|
</li>
|
|
<li><p class="first">Install wxPython like this. Remember to add any additional flags
|
|
you added for the build such as UNICODE or USE_SWIG:</p>
|
|
<pre class="literal-block">
|
|
python setup.py install
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">Copy the wxWidgets DLLs to the wx package directory so they can be
|
|
found at runtime by the extension modules without requiring that
|
|
they be installed on the PATH:</p>
|
|
<pre class="literal-block">
|
|
copy %WXWIN%\\lib\\vc_dll\\wx*h_*.dll c:\\Python25\\Lib\\site-packages\\wx
|
|
</pre>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|