095315e20d
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@36730 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
437 lines
21 KiB
HTML
437 lines
21 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.3.7: http://docutils.sourceforge.net/" />
|
|
<title>Building wxPython 2.6 for Development and Testing</title>
|
|
<link rel="stylesheet" href="default.css" type="text/css" />
|
|
</head>
|
|
<body>
|
|
<div class="document" id="building-wxpython-2-6-for-development-and-testing">
|
|
<h1 class="title">Building wxPython 2.6 for Development and Testing</h1>
|
|
<p>This file describes how I build wxWidgets and wxPython while doing
|
|
development and testing, and is meant to help other people that want
|
|
to do the same thing. I'll assume that you are using either a CVS
|
|
snapshot from <a class="reference" href="http://wxWidgets.org/snapshots/">http://wxWidgets.org/snapshots/</a>, a checkout from CVS, or
|
|
one of the released wxPython-src-2.6.* tarballs. I'll also assume that
|
|
you know your way around your system, the compiler, etc. and most
|
|
importantly, that you know what you are doing! ;-)</p>
|
|
<p>If you want to also install the version of wxPython you build to be in
|
|
your site-packages dir and be your default version of wxPython, then a
|
|
few additional steps are needed, and you may want to use slightly
|
|
different options. See the <a class="reference" href="INSTALL.html">INSTALL</a> document for more details. If
|
|
you only use the instructions in this <a class="reference" href="BUILD.html">BUILD</a> document file then you
|
|
will end up with a separate installation of wxPython and you can
|
|
switch back and forth between this and the release version that you
|
|
may already have installed.</p>
|
|
<p>If you want to make changes to any of the <tt class="docutils literal"><span class="pre">*.i</span></tt> files, (SWIG
|
|
interface definition files,) or to regenerate the extension sources or
|
|
renamer modules, then you will need an up to date version of SWIG,
|
|
plus some patches. Get the sources for version 1.3.24, and then apply
|
|
the patches in wxPython/SWIG and then build SWIG like normal. See the
|
|
README.txt in the wxPython/SWIG dir for details about each patch and
|
|
also info about those that may already have been applied to the SWIG
|
|
sources. If you install this build of SWIG to a location that is not
|
|
on the PATH (so it doesn't interfere with an existing SWIG install for
|
|
example) then you can set a setup.py command-line variable named SWIG
|
|
to be the full path name of the executable and the wxPython build will
|
|
use it. See below for an example.</p>
|
|
<p>In the text below I'll use WXDIR with environment variable syntax
|
|
(either $WXDIR or %WXDIR%) to refer to the top level directory where
|
|
your wxWidgets and wxPython sources are located. It will equate to
|
|
whereever you checked out the wxWidgets module from CVS, or untarred
|
|
the wxPython-src tarball to. You can either substitute the $WXDIR text
|
|
below with your actual dir, or set the value in the environment and
|
|
use it just like you see it below.</p>
|
|
<p>If you run into what appears to be compatibility issues between
|
|
wxWidgets and wxPython while building wxPython, be sure you are using
|
|
the wxWidgets sources included with the wxPython-src tarball or the
|
|
CVS snapshot, and not a previously installed version or a version
|
|
installed from one of the standard wxWidgets installers. With the
|
|
"unstable" releases (have a odd-numbered minor release value, where
|
|
the APIs are allowed to change) there are often significant
|
|
differences between the W.X.Y release of wxWidgets and the W.X.Y.Z
|
|
release of wxPython.</p>
|
|
<div class="section" id="building-on-unix-like-systems-e-g-linux-and-os-x">
|
|
<h1><a name="building-on-unix-like-systems-e-g-linux-and-os-x">Building on Unix-like Systems (e.g. Linux and OS X)</a></h1>
|
|
<p>These platforms are built almost the same way while in development
|
|
so I'll combine the descriptions about their build process here.
|
|
First we will build wxWidgets and install it to an out of the way
|
|
place, then do the same for wxPython.</p>
|
|
<ol class="arabic">
|
|
<li><p class="first">Create a build directory in the main wxWidgets dir, and configure
|
|
wxWidgets. If you want to have multiple builds with different
|
|
configure options, just use different subdirectories. I normally
|
|
put the configure command in a script named ".configure" in each
|
|
build dir so I can easily blow away everything in the build dir and
|
|
rerun the script without having to remember the options I used
|
|
before:</p>
|
|
<pre class="literal-block">
|
|
cd $WXDIR
|
|
mkdir bld
|
|
cd bld
|
|
../configure --prefix=/opt/wx/2.6 \
|
|
--with-gtk \
|
|
--with-gnomeprint \
|
|
--with-opengl \
|
|
--enable-debug \
|
|
--enable-geometry \
|
|
--enable-sound --with-sdl \
|
|
--enable-mediactrl \
|
|
--enable-display \
|
|
--disable-debugreport \
|
|
</pre>
|
|
<p>On OS X of course you'll want to use --with-mac instead of
|
|
--with-gtk and --with-gnomeprint.</p>
|
|
<p><strong>NOTE</strong>: Due to a recent change there is currently a dependency
|
|
problem in the multilib builds of wxWidgets on OSX, so I have
|
|
switched to using a monolithic build. That means that all of the
|
|
core wxWidgets code is placed in in one shared library instead of
|
|
several. wxPython can be used with either mode, so use whatever
|
|
suits you on Linux and etc. but use monolithic on OSX. To switch
|
|
to the monolithic build of wxWidgets just add this configure flag:</p>
|
|
<pre class="literal-block">
|
|
--enable-monolithic \
|
|
</pre>
|
|
<p>By default GTK 2.x will be used for the build. If you would rather
|
|
use GTK 1.2.x for some reason then you can force configure to use
|
|
it by changing the --with-gtk flag to specify it like this:</p>
|
|
<pre class="literal-block">
|
|
--with-gtk=1 \
|
|
</pre>
|
|
<p>To make the wxWidgets build be unicode enabled (strongly
|
|
recommended if you are building with GTK2) then add the following.
|
|
When wxPython is unicode enabled then all strings that are passed
|
|
to wx functions and methods will first be converted to unicode
|
|
objects, and any 'strings' returned from wx functions and methods
|
|
will actually be unicode objects.:</p>
|
|
<pre class="literal-block">
|
|
--enable-unicode \
|
|
</pre>
|
|
<p>Notice that I used a prefix of /opt/wx/2.6. You can use whatever
|
|
path you want, such as a path in your HOME dir or even one of the
|
|
standard prefix paths such as /usr or /usr/local if you like, but
|
|
using /opt this way lets me easily have multiple versions and ports
|
|
of wxWidgets "installed" and makes it easy to switch between them,
|
|
without impacting any versions of wxWidgets that may have been
|
|
installed via an RPM or whatever. For the rest of the steps below
|
|
be sure to also substitute "/opt/wx/2.6" with whatever prefix you
|
|
choose for your build.</p>
|
|
<p>If you want to use the image and zlib libraries included with
|
|
wxWidgets instead of those already installed on your system, (for
|
|
example, to reduce dependencies on 3rd party libraries) then you
|
|
can add these flags to the configure command:</p>
|
|
<pre class="literal-block">
|
|
--with-libjpeg=builtin \
|
|
--with-libpng=builtin \
|
|
--with-libtiff=builtin \
|
|
--with-zlib=builtin \
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">To build and install wxWidgets you could just use the "make"
|
|
command but there are other libraries besides the main wxWidgets
|
|
libs that also need to be built so again I make a script to do it
|
|
all for me so I don't forget anything. This time it is called
|
|
".make" (I use the leading "." so when I do <tt class="docutils literal"><span class="pre">rm</span> <span class="pre">-r</span> <span class="pre">*</span></tt> in my build
|
|
dir I don't lose my scripts too.) This is what it looks like:</p>
|
|
<pre class="literal-block">
|
|
make $* \
|
|
&& make -C contrib/src/animate $* \
|
|
&& make -C contrib/src/gizmos $* \
|
|
&& make -C contrib/src/stc $*
|
|
</pre>
|
|
<p>So you just use .make as if it where make, but don't forget to set
|
|
the execute bit on .make first!:</p>
|
|
<pre class="literal-block">
|
|
.make
|
|
.make install
|
|
</pre>
|
|
<p>When it's done you should have an installed set of files under
|
|
/opt/wx/2.6 containing just wxWidgets. Now to use this version of
|
|
wxWidgets you just need to add /opt/wx/2.6/bin to the PATH and set
|
|
LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.6/lib.</p>
|
|
</li>
|
|
<li><p class="first">I also have a script to help me build wxPython and it is checked in
|
|
to the CVS as wxWidgets/wxPython/b, but you probably don't want to
|
|
use it as it's very cryptic and expects that you want to run SWIG,
|
|
so if you don't have the latest patched up version of SWIG then
|
|
you'll probably get stuck. So I'll just give the raw commands
|
|
instead.</p>
|
|
<p>We're not going to install the development version of wxPython with
|
|
these commands, so it won't impact your already installed version
|
|
of the latest release. You'll be able test with this version when
|
|
you want to, and use the installed release version the rest of the
|
|
time. If you want to install the development version please read
|
|
INSTALL.txt.</p>
|
|
<p>If you have more than one version of Python on your system then be
|
|
sure to use the version of Python that you want to use when running
|
|
wxPython programs to run the setup.py commands below. I'll be
|
|
using python2.3.</p>
|
|
<p>Make sure that the first wx-config found on the PATH is the one you
|
|
installed above, and then change to the $WXDIR/wxPython dir and
|
|
run the this command:</p>
|
|
<pre class="literal-block">
|
|
cd $WXDIR/wxPython
|
|
python2.3 setup.py build_ext --inplace --debug
|
|
</pre>
|
|
<p>If your new wx-config script is not on the PATH, or there is some
|
|
other version of it found first, then you can add this to the
|
|
command line to ensure your new one is used instead:</p>
|
|
<pre class="literal-block">
|
|
WX_CONFIG=/opt/wx/2.6/bin/wx-config
|
|
</pre>
|
|
<p>By default setup.py will assume that you built wxWidgets to use
|
|
GTK2. If you built wxWidgets to use GTK 1.2.x then you should add
|
|
this flag to the command-line:</p>
|
|
<pre class="literal-block">
|
|
WXPORT=gtk
|
|
</pre>
|
|
<p>If you would like to do a Unicode enabled build (all strings sent
|
|
to or retruned from wx functions are Unicode objects) and your
|
|
wxWidgets was built with unicode enabled then add this flag:</p>
|
|
<pre class="literal-block">
|
|
UNICODE=1
|
|
</pre>
|
|
<p>If you are wanting to have the source files regenerated with swig,
|
|
then you need to turn on the USE_SWIG flag and optionally tell it
|
|
where to find the new swig executable, so add these flags:</p>
|
|
<pre class="literal-block">
|
|
USE_SWIG=1 SWIG=/opt/swig/bin/swig
|
|
</pre>
|
|
<p>If you get errors about being unable to find libGLU, wxGLCanvas
|
|
being undeclared, or something similar then you can add
|
|
BUILD_GLCANVAS=0 to the setup.py command line to disable the
|
|
building of the glcanvas module.</p>
|
|
<p>When the setup.py command is done you should have fully populated
|
|
wxPython and wx packages locally in $WXDIR/wxPython/wxPython and
|
|
$WXDIR/wxPython/wx, with all the extension modules (<tt class="docutils literal"><span class="pre">*.so</span></tt> files)
|
|
located in the wx package.</p>
|
|
</li>
|
|
<li><p class="first">To run code with the development version of wxPython, just set the
|
|
PYTHONPATH to the wxPython dir located in the source tree. For
|
|
example:</p>
|
|
<pre class="literal-block">
|
|
export LD_LIBRARY_PATH=/opt/wx/2.6/lib
|
|
export PYTHONPATH=$WXDIR/wxPython
|
|
cd $WXDIR/wxPython/demo
|
|
python2.3 demo.py
|
|
</pre>
|
|
<p>OS X NOTE: You need to use "pythonw" on the command line to run
|
|
wxPython applications. This version of the Python executable is
|
|
part of the Python Framework and is allowed to interact with the
|
|
display. You can also double click on a .py or a .pyw file from
|
|
the finder (assuming that the PythonLauncher app is associated with
|
|
these file extensions) and it will launch the Framework version of
|
|
Python for you. For information about creating Applicaiton Bundles
|
|
of your wxPython apps please see the wiki and the mail lists.</p>
|
|
<p>SOLARIS NOTE: If you get unresolved symbol errors when importing
|
|
wxPython and you are running on Solaris and building with gcc, then
|
|
you may be able to work around the problem by uncommenting a bit of
|
|
code in config.py and building again. Look for 'SunOS' in config.py
|
|
and uncomment the block containing it. The problem is that Sun's ld
|
|
does not automatically add libgcc to the link step.</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
<div class="section" id="building-on-windows">
|
|
<h1><a name="building-on-windows">Building on Windows</a></h1>
|
|
<p>The Windows builds currently require the use of Microsoft Visual C++.
|
|
Theoretically, other compilers (such as mingw32 or the Borland
|
|
compilers) can also be used but I've never done the work to make that
|
|
happen. If you want to try that then first you'll want to find out if
|
|
there are any tricks that have to be done to make Python extension
|
|
modules using that compiler, and then make a few changes to setup.py
|
|
to accommodate that. (And send the patches to me.) If you plan on
|
|
using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
|
|
have to build Python and any other extension modules that you use with
|
|
that compiler because a different version of the C runtime library is
|
|
used. The Python executable that comes from PythonLabs and the
|
|
wxPython extensions that I distribute are built with MSVC 6 with all
|
|
the Service Packs applied. This policy will change with Python 2.4
|
|
and MSVC 7.1 will be used starting with that version.</p>
|
|
<p>If you want to build a debuggable version of wxWidgets and wxPython you
|
|
will need to have also built a debug version of Python and any other
|
|
extension modules you need to use. You can tell if you have them
|
|
already if there is a _d in the file names, for example python_d.exe
|
|
or python23_d.dll. If you don't need to trace through the C/C++ parts
|
|
of the code with the debugger then building the normal (or hybrid)
|
|
version is fine, and you can use the regular python executables with
|
|
it.</p>
|
|
<p>Starting with 2.5.3.0 wxPython can be built for either the monlithic
|
|
or the multi-lib wxWidgets builds. (Monolithic means that all the
|
|
core wxWidgets code is in one DLL, and multi-lib means that the core
|
|
code is divided into multiple DLLs.) To select which one to use
|
|
specify the MONOLITHIC flag for both the wxWidgets build and the
|
|
wxPython build as shown below, setting it to either 0 or 1.</p>
|
|
<p>Just like the unix versions I also use some scripts to help me build
|
|
wxWidgets, but I use some non-standard stuff to do it. So if you have
|
|
bash (cygwin or probably MSYS too) or 4NT plus unix-like cat and sed
|
|
programs then there is a copy of my wxWidgets build scripts in
|
|
%WXDIR%\wxPython\distrib\msw. Just copy them to
|
|
%WXDIR%\build\msw and you can use them to do your build, otherwise
|
|
you can do everything by hand as described below. But if you do work
|
|
by hand and something doesn't seem to be working correctly please
|
|
refer to the build scripts to see what may need to be done
|
|
differently.</p>
|
|
<p>The *.btm files are for 4NT and the others are for bash. They are:</p>
|
|
<pre class="literal-block">
|
|
.make/.make.btm Builds the main lib and the needed contribs
|
|
.mymake/.mymake.btm Builds just one lib, use by .make
|
|
.makesetup.mk A makefile that will copy and edit setup.h
|
|
as needed for the different types of builds
|
|
</pre>
|
|
<p>Okay. Here's what you've been waiting for, the instructions! Adapt
|
|
accordingly if you are using the bash shell.</p>
|
|
<ol class="arabic">
|
|
<li><p class="first">Set an environment variable to the root of the wxWidgets source
|
|
tree. This is used by the makefiles:</p>
|
|
<pre class="literal-block">
|
|
set WXWIN=%WXDIR%
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">Copy setup0.h to setup.h:</p>
|
|
<pre class="literal-block">
|
|
cd %WXDIR%\include\wx\msw
|
|
copy setup0.h setup.h
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">Edit %WXDIR%\include\wx\msw\setup.h and change a few settings:</p>
|
|
<pre class="literal-block">
|
|
wxDIALOG_UNIT_COMPATIBILITY 0
|
|
wxUSE_DEBUG_CONTEXT 1
|
|
wxUSE_MEMORY_TRACING 1
|
|
wxUSE_DIALUP_MANAGER 0
|
|
wxUSE_GLCANVAS 1
|
|
wxUSE_POSTSCRIPT 1
|
|
wxUSE_AFM_FOR_POSTSCRIPT 0
|
|
wxUSE_DISPLAY 1
|
|
wxUSE_DEBUGREPORT 0
|
|
</pre>
|
|
<p>If you are using my build scripts then a few more settings will be
|
|
changed and then a copy of setup.h is placed in a subdir of
|
|
%WXWIN%\libvc_dll. If you are doing it by hand and making a
|
|
UNICODE build, then also change these:</p>
|
|
<pre class="literal-block">
|
|
wxUSE_UNICODE 1
|
|
wxUSE_UNICODE_MSLU 1
|
|
</pre>
|
|
<p>If you are doing a "hybrid" build (which is the same as the
|
|
binaries that I release) then also change these:</p>
|
|
<pre class="literal-block">
|
|
wxUSE_MEMORY_TRACING 0
|
|
wxUSE_DEBUG_CONTEXT 0
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">Make sure that %WXDIR%\lib\vc_dll directory is on the PATH. The
|
|
wxWidgets DLLs will end up there as part of the build and so you'll
|
|
need it on the PATH for them to be found at runtime.</p>
|
|
</li>
|
|
<li><p class="first">Change to the %WXDIR%\build\msw directory</p>
|
|
<blockquote>
|
|
<p>cd %WXDIR%\build\msw</p>
|
|
</blockquote>
|
|
</li>
|
|
<li><p class="first">If using my scripts then use the .make.btm command to build
|
|
wxWidgets. It needs one command-line parameter which controls what
|
|
kind of build(s) to do. Use one of the following:</p>
|
|
<pre class="literal-block">
|
|
debug Build debug version
|
|
hybrid Build hybrid version
|
|
both Both debug and hybrid
|
|
debug-uni Build a debug unicode library
|
|
hybrid-uni Hybrid unicode (see the pattern yet? ;-)
|
|
both-uni and finally both unicode libraries
|
|
</pre>
|
|
<p>For example:</p>
|
|
<pre class="literal-block">
|
|
.make hybrid
|
|
</pre>
|
|
<p>You can also pass additional command line parameters as needed and
|
|
they will all be passed on to the nmake commands, for example to
|
|
clean up the build:</p>
|
|
<pre class="literal-block">
|
|
.make hybrid clean
|
|
</pre>
|
|
<p>If <em>not</em> using my scripts then you can do it by hand by directly
|
|
executing nmake with a bunch of extra command line parameters.
|
|
The base set are:</p>
|
|
<pre class="literal-block">
|
|
nmake -f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1
|
|
</pre>
|
|
<p>If doing a debug build then add:</p>
|
|
<pre class="literal-block">
|
|
BUILD=debug
|
|
</pre>
|
|
<p>otherwise add these:</p>
|
|
<pre class="literal-block">
|
|
DEBUG_FLAG=1 CXXFLAGS=/D__NO_VC_CRTDBG__ WXDEBUGFLAG=h BUILD=release
|
|
</pre>
|
|
<p>If doing a Unicode build then add these flags:</p>
|
|
<pre class="literal-block">
|
|
UNICODE=1 MSLU=1
|
|
</pre>
|
|
<p>Now, from the %WXDIR%\build\msw directory run nmake with your
|
|
selection of command-line flags as described above. Repeat this
|
|
same command from the following directories in order to build the
|
|
contrib libraries:</p>
|
|
<pre class="literal-block">
|
|
%WXDIR%\contrib\build\animate
|
|
%WXDIR%\contrib\build\gizmos
|
|
%WXDIR%\contrib\build\stc
|
|
</pre>
|
|
</li>
|
|
<li><p class="first">When that is all done it will have built the main wxWidgets DLLs
|
|
and also some of the contribs DLLs. There should be a ton of DLLs
|
|
and lots of lib files and other stuff in %WXDIR%\lib\vc_dll.</p>
|
|
</li>
|
|
<li><p class="first">Building wxPython on Windows is very similar to doing it for the
|
|
unix systems. We're not going to install the development version
|
|
of wxPython with these commands, so it won't impact your already
|
|
installed version of the latest release. You'll be able to test
|
|
with this version when you want to, and use the installed release
|
|
version the rest of the time. If you ever do want to install the
|
|
development version please refer to INSTALL.txt.</p>
|
|
<p>Change to the %WXDIR%\wxPython dir and run the this command,
|
|
making sure that you use the version of python that you want to
|
|
build for (if you have more than one on your system) and to match
|
|
the MONOLITHIC flag with how you built wxWidgets:</p>
|
|
<pre class="literal-block">
|
|
cd %WXDIR%\wxPython
|
|
python setup.py build_ext --inplace MONOLITHIC=1
|
|
</pre>
|
|
<p>If you are wanting to have the source files regenerated with swig,
|
|
then you need to turn on the USE_SWIG flag and optionally tell it
|
|
where to find the new swig executable, so add these flags:</p>
|
|
<pre class="literal-block">
|
|
USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe
|
|
</pre>
|
|
<p>If you built a Unicode version of wxWidgets and want to also build
|
|
the Unicode version of wxPython then add this flag:</p>
|
|
<pre class="literal-block">
|
|
UNICODE=1
|
|
</pre>
|
|
<p>If you have a debug version of Python and wxWidgets and want to
|
|
build a debug version of wxPython too, add the --debug flag to the
|
|
command line. You should then end up with a set of <tt class="docutils literal"><span class="pre">*_d.pyd</span></tt>
|
|
files in the wx package and you'll have to run <tt class="docutils literal"><span class="pre">python_d.exe</span></tt> to
|
|
use them. The debug and hybrid(release) versions can coexist.</p>
|
|
<p>When the setup.py command is done you should have fully populated
|
|
wxPython and wx packages locally in %WXDIR%/wxPython/wxPython and
|
|
%WXDIR%/wxPython/wx, with all the extension modules (<tt class="docutils literal"><span class="pre">*.pyd</span></tt>
|
|
files) located in the wx package.</p>
|
|
</li>
|
|
<li><p class="first">To run code with the development version of wxPython, just set the
|
|
PYTHONPATH to the wxPython dir in the CVS tree. For example:</p>
|
|
<pre class="literal-block">
|
|
set PYTHONPATH=%WXDIR%\wxPython
|
|
cd %WXDIR\wxPython\demo
|
|
python demo.py
|
|
</pre>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|