1e4a197e4c
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@19793 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
304 lines
12 KiB
Plaintext
304 lines
12 KiB
Plaintext
Building wxPython on Win32
|
|
--------------------------
|
|
|
|
|
|
Building wxPython for use on win32 systems is a fairly simple process
|
|
consisting of just a few steps. However depending on where you get
|
|
your sources from and what your desired end result is, there are
|
|
several permutations of those steps. At a high level the basic steps
|
|
are:
|
|
|
|
1. Get the sources
|
|
2. Build the wxWindows DLL
|
|
3. Build and Install wxPython
|
|
|
|
We'll go into more detail of each of these steps below, but first a
|
|
few bits of background information on tools.
|
|
|
|
I use a tool called SWIG (http://www.swig.org) to help generate the
|
|
C++ sources used in the wxPython extension module. However you don't
|
|
need to have SWIG unless you want to modify the *.i files. I've made
|
|
several modifications to SWIG specific to wxPython's needs and so the
|
|
modified sources are included in the wx CVS at.../wxPython/wxSWIG.
|
|
But because of the size and since most people won't need it my SWIG is
|
|
not included in the wxPythonSrc tarball. You'll need to get it from
|
|
CVS or a CVS snapshot.
|
|
|
|
If you need to modify the *.i files for wxPython then change to this
|
|
directory and run:
|
|
|
|
nmake -f makefile.vc
|
|
|
|
Then you'll need to change a flag in the setup.py script as described
|
|
below so the wxPython build process will use SWIG if needed.
|
|
|
|
I use the new Python Distutils tool to build wxPython. It is included
|
|
with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
|
|
you'll need to download and install Distutils 1.0 from
|
|
http://www.python.org/sigs/distutils-sig/
|
|
|
|
I use Microsoft Visual C++ 6.0 (5.0 with the service packs should work
|
|
also) to compile the wxPython C++ sources. Since I am using Distutils
|
|
it should be easier now to build with other win32 compilers such as
|
|
the free mingw32 or Borland compilers, but I havn't tried them yet.
|
|
If anybody wants to try it I'll take any required patches for the
|
|
setup script and for these instructions.
|
|
|
|
|
|
|
|
UNICODE
|
|
-------
|
|
|
|
To build the version of wxWindows/wxPython that uses the unicode
|
|
version of the Win32 APIs, just follow the steps below with these
|
|
changes:
|
|
|
|
a. You'll need the MSLU runtime DLL and import lib. The former can
|
|
be downloaded from Microsoft, the latter is part of the latest
|
|
Platform SDK from Microsoft (see msdn.microsoft.com for
|
|
details). An alternative implementation of import lib can be
|
|
downloaded from http://libunicows.sourceforge.net
|
|
|
|
b. Add "UNICODE=1 MSLU=1" to the nmake command line when building
|
|
wxWindows.
|
|
|
|
c. Add "UNICODE=1" to the setup.py commandline when building
|
|
wxPython.
|
|
|
|
d. See the notes in CHANGES.txt about unicode.
|
|
|
|
|
|
And now on to the fun stuff...
|
|
|
|
|
|
|
|
|
|
1. Get the sources
|
|
------------------
|
|
|
|
A. You can either use a tarball with the released version of the
|
|
source code for wxWindows/wxPython, or you can get current
|
|
development sources from the CVS repository. (Some information
|
|
about annonymous CVS access is at the http://wxwindows.org/cvs.htm
|
|
site.) The advantage of using CVS is that you can easily update as
|
|
soon as the developers check in new sources or fixes. The
|
|
advantage of using a released version is that it usually has had
|
|
more thorough testing done. You can decide which method is best
|
|
for you. The released version file is named
|
|
wxPythonSrc-[version].tar.gz and is available from the wxPython
|
|
website at http://wxpython.org/download.php. You can use WinZip to
|
|
unpack it if you don't have tar and gzip.
|
|
|
|
|
|
B. Once you get the sources be sure to put them in a path without a
|
|
space in it (i.e., NOT c:\Program Files\wx) and set an environment
|
|
variable named WXWIN to the top level directory. For example:
|
|
|
|
set WXWIN=c:\wx\wxPythonSrc-2.4.0.4
|
|
|
|
You'll probably want to add that line to your autoexec.bat or
|
|
System Properties depending on the type of system you are on.
|
|
|
|
|
|
C. Change to the %WXWIN%\include\wx\msw directory and copy setup0.h to
|
|
setup.h and then edit setup.h. This is how you control which parts
|
|
of wxWindows are compiled into or left out of the build, simply by
|
|
turning options on or off. I have the following differences from
|
|
the default setup0.h in my setup.h, but you can experiment with
|
|
other settings if you like:
|
|
|
|
|
|
WXWIN_COMPATIBILITY_2_2 0
|
|
wxDIALOG_UNIT_COMPATIBILITY 0
|
|
wxUSE_DEBUG_CONTEXT 1
|
|
wxUSE_MEMORY_TRACING 1
|
|
wxUSE_CMDLINE_PARSER 0
|
|
wxUSE_FSVOLUME 0
|
|
wxUSE_DIALUP_MANAGER 0
|
|
wxUSE_DYNAMIC_LOADER 0
|
|
wxUSE_TREELAYOUT 0
|
|
wxUSE_MS_HTML_HELP 0
|
|
wxUSE_POSTSCRIPT 1
|
|
|
|
|
|
** NEW **
|
|
Be sure that wxUSE_GLCANVAS is defined to be 0 as wxPython now
|
|
keeps its own copy of the glcanvas sources and expects that it is
|
|
not in the main library. This is done to reduce the number of
|
|
dependant DLLs on the core library and therefore help reduce
|
|
startup time.
|
|
|
|
|
|
|
|
2. Build the wxWindows DLL
|
|
---------------------------
|
|
|
|
A. Although MSVC project files are provided I always use the makefiles
|
|
to build wxWindows because by default the flags are compatible with
|
|
Python, (and I make sure they stay that way.) You would have to
|
|
edit the project files a bit to make it work otherwise.
|
|
|
|
|
|
B. There are three different types of wxWindows DLLs that can be
|
|
produced by the VC makefile simply by providing a flag on the nmake
|
|
command-line, I call the three types DEBUG, FINAL, and HYBRID.
|
|
Here are some more details:
|
|
|
|
DEBUG Specified with "FINAL=0" and produces a DLL named
|
|
wxmsw[version]d.dll. This DLL is compiled with full
|
|
debugging information and with the __WXDEBUG__ macro set,
|
|
which enables some debugging-only code in wxWindows such
|
|
as assertions and failure log messages. The /MDd flag is
|
|
used which means that it is linked with the debugging
|
|
version of the C runtime library and also that you must
|
|
use the debugging version of Python, (python_d.exe and
|
|
pythonXX_d.dll) which also means that all extensions
|
|
loaded by Python should also have the _d in the name.
|
|
With this option you can use the MSVC debugger to trace
|
|
though the Python interpreter, as well as the code for the
|
|
wxPython extension and the wxWindows DLL.
|
|
|
|
FINAL Specified with "FINAL=1" and produces a DLL named
|
|
wxmsw[version].dll. This DLL is compiled with optimizations
|
|
turned on and without debugging information and without
|
|
__WXDEBUG__. The /MD flag is used which means that you
|
|
can use this version with the standard python.exe.
|
|
|
|
HYBRID Specified with "FINAL=hybrid" and produces a DLL named
|
|
wxmsw[version]h.dll. This DLL is almost the same as the
|
|
FINAL version except the __WXDEBUG__ is used which means
|
|
that you will get extra runtime assertions and validations
|
|
from wxWindows. If any of these fail then they are turned
|
|
into a Python exception that you can catch and deal with
|
|
in your code. This is the version that I use when making
|
|
the binary installer for win32.
|
|
|
|
|
|
Since different DLL names and object file directories are used you
|
|
can build all three types if you like.
|
|
|
|
|
|
C. Change to the %WXWIN%\src\msw directory and type the following command,
|
|
using the value for FINAL that you want:
|
|
|
|
nmake -f makefile.vc dll FINAL=hybrid
|
|
|
|
Your machine will then crunch away for possibly a long time,
|
|
depending on your hardware, and when it's done you should have a
|
|
DLL and some library files in %WXWIN%\lib.
|
|
|
|
|
|
D. You'll either need to add %WXWIN%\lib to the PATH or copy the DLL
|
|
file to a directory already on the PATH so the DLL can be found at
|
|
runtime. Another option is to copy the DLL to the directory that
|
|
the wxPython pacakge is installed to, for example,
|
|
c:\Python22\lib\site-packages\wxPython.
|
|
|
|
|
|
E. You can test your build by changing to one of the directories under
|
|
%WXWIN%\samples or %WXWIN\demos and typing (using the right FINAL flag):
|
|
|
|
nmake -f makefile.vc FINAL=hybrid WXUSINGDLL=1
|
|
|
|
and then executing the resulting .exe file.
|
|
|
|
|
|
|
|
|
|
3. Build and Install wxPython
|
|
-----------------------------
|
|
|
|
A. As mentioned previouslly, wxPython is built with the standard
|
|
Python Distutils tool. If you are using Python 2.0 or later you
|
|
are all set, otherwise you need to download and install Distutils
|
|
1.0 from http://www.python.org/sigs/distutils-sig/.
|
|
|
|
|
|
B. Change to the root wxPython directory and look at the setup.py
|
|
file. This is the script that configures and defines all the
|
|
information that Distutils needs to build wxPython. There are some
|
|
options near the begining of the script that you may want or need
|
|
to change based on what options you have selected up to this point,
|
|
(type of DLL built, sources from tar.gz or from CVS, etc.) You can
|
|
either change these flags directly in setup.py or supply them on
|
|
the command-line.
|
|
|
|
BUILD_GLCANVAS Set to zero if you don't want to build the
|
|
Open GL canvas extension module.
|
|
|
|
BUILD_OGL Set to zero if you don't want to build the
|
|
Object Graphics Library extension module.
|
|
|
|
BUILD_STC Set to zero if you don't want to build the
|
|
wxStyledTextCtrl (the Scintilla wrapper)
|
|
extension module.
|
|
|
|
USE_SWIG If you have edited any of the *.i files you
|
|
will need to set this flag to non-zero so SWIG
|
|
will be executed to regenerate the wrapper C++
|
|
and shadow python files.
|
|
|
|
etc.
|
|
|
|
|
|
C. To build and install wxPython you simply need to execute the
|
|
setup.py script. If you have more than one version of Python
|
|
installed, be sure to execute setup.py with the version you want to
|
|
build wxPython for.
|
|
|
|
Depending on what kind of wxWindows DLL you built there are
|
|
different command-line parameters you'll want to pass to setup (in
|
|
addition to possibly one or more of the above):
|
|
|
|
FINAL: python setup.py install
|
|
|
|
DEBUG: python setup.py build --debug install
|
|
|
|
HYBRID: python setup.py HYBRID=1 install
|
|
|
|
NOTE: If you get an internal compiler error from MSVC then you
|
|
need to edit setup.py and add in the /GX- flag that is normally
|
|
commented out. Just search for "GX-" and uncomment it so it is put
|
|
into the cflags list.
|
|
|
|
If you would like to install to someplace besides the Python
|
|
site-packages directory (such as to your home directory) then you
|
|
can add "--root=<path>" after the "install" command. To use
|
|
wxPython like this you'll need to ensure that the directory
|
|
containing wxPyrthon is contained in in the PYTHONPATH environment
|
|
variable.
|
|
|
|
|
|
D. At this point you should be able to change into the wxPython\demo
|
|
directory and run the demo:
|
|
|
|
python demo.py
|
|
|
|
|
|
E. If you would like to make a test build that doesn't overwrite the
|
|
installed version of wxPython you can do so with one of these
|
|
commands instead of the install command above:
|
|
|
|
FINAL: python setup.py build_ext --inplace
|
|
|
|
DEBUG: python setup.py build_ext --debug --inplace
|
|
|
|
HYBRID: python setup.py HYBRID=1 build_ext --inplace
|
|
|
|
This will build the wxPython package in the local wxPython
|
|
directory instead of installing it under your Python installation.
|
|
To run using this test version just add the base wxPython source
|
|
directory to the PYTHONPATH:
|
|
|
|
set PYTHONPATH=%WXDIR%\wxPython
|
|
cd %WXDIR%\wxPython\demo
|
|
python demo.py
|
|
|
|
|
|
That's all folks!
|
|
|
|
|
|
-----------------
|
|
robin@alldunn.com
|
|
|