990416e0bd
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@5797 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
149 lines
5.5 KiB
Plaintext
149 lines
5.5 KiB
Plaintext
Build Instructions
|
|
------------------
|
|
I used SWIG (http://www.swig.org) to create the source code for the
|
|
extension module. This enabled me to only have to deal with a small
|
|
amount of code and only have to bother with the exceptional issues.
|
|
SWIG takes care of the rest and generates all the repetative code for
|
|
me. You don't need SWIG to build the extension module as all the
|
|
generated C++ code is included under the src directory.
|
|
|
|
I added a few minor features to SWIG to control some of the code
|
|
generation. If you want to play around with this you will need to get
|
|
a recent version of SWIG from their CVS or from a daily build. See
|
|
http://www.swig.org/ for details.
|
|
|
|
wxPython is organized as a Python package. This means that the
|
|
directory containing the results of the build process should be a
|
|
subdirectory of a directory on the PYTHONPATH. (And preferably should
|
|
be named wxPython.) You can control where the build process will dump
|
|
wxPython by setting the TARGETDIR variable for the build utility, (see
|
|
below.)
|
|
|
|
|
|
1. Build and install wxWindows as described in its BuildCVS.txt or
|
|
INSTALL.txt file.
|
|
|
|
1a. Building wxWindows on Unix/Linux.
|
|
|
|
For *nix systems I run configure with these flags:
|
|
|
|
--with-gtk
|
|
--with-libjpeg
|
|
--without-odbc
|
|
--enable-unicode=no
|
|
--enable-threads=yes
|
|
--enable-socket=yes
|
|
--enable-static=no
|
|
--enable-shared=yes
|
|
--disable-std_iostreams
|
|
|
|
You can use whatever flags you want, but these work for me. Be
|
|
sure to run "make install" to install the wxWindows headers and
|
|
shared library. You can check where the wxPython build will expect
|
|
to find them by running "wx-config --cflags" and "wx-config --libs"
|
|
|
|
1b. Building wxWindows on Win32.
|
|
|
|
For Win32 systems I use Visual C++ 6.0, but 5.0 should work. The
|
|
wxPython build utility currently does not support any other win32
|
|
compilers. Be sure to copy include/wx/msw/setup0.h to
|
|
include/wx/msw/setup.h and edit it for the options you want. At a
|
|
minimum you should set the following:
|
|
|
|
wxUSE_NEW_GRID 0
|
|
wxUSE_GLOBAL_MEMORY_OPERATORS 0
|
|
wxUSE_LIBTIFF 1
|
|
|
|
I also change these:
|
|
|
|
wxUSE_DIALUP_MANAGER 0
|
|
wxUSE_SOCKETS 0
|
|
wxUSE_FS_INET 0
|
|
|
|
There are probably other flags that can be disabled to remove
|
|
things not being used in wxPython, but I havn't investigated all
|
|
the potential configurations yet.
|
|
|
|
I find it easiest to build wxWindows using the makefiles, that way
|
|
I don't have to worry about what the IDE might be doing behind the
|
|
scenes that might screw things up. Simply go to the src/msw
|
|
directory and run:
|
|
|
|
nmake -f makefile.vc CRTFLAG=/MD EXTRAFLAGS=-D__NO_VC_CRTDBG__ dll pch
|
|
|
|
If you want to make a release build, add FINAL=1 to the nmake
|
|
command, as well as to build.local for wxPython, (see below.)
|
|
|
|
|
|
2. For either platform, you should be sure to set an environment
|
|
variable named WXWIN to be the path to the top of the wxWindows
|
|
tree.
|
|
|
|
|
|
3. If you are working from a copy of the code retrieved from CVS, then
|
|
you will find wxPython in $WXWIN/utils/wxPython. If you are
|
|
working from the tar.gz or .zip files then you will probably want
|
|
to unpack wxPython in the $WXWIN/utils directory and rename the new
|
|
directory to wxPython (or use a symlink.) If you want to keep it
|
|
in a separate directory then you can change where the build.py tool
|
|
expects to find it by creating a file named build.local (see step 7
|
|
for more examples about build.local,) containing something like
|
|
this:
|
|
|
|
WXPSRCDIR = "~/MyStuff/wxPython-2.1.11/src"
|
|
|
|
|
|
4. At this point you may want to make an alias or symlink, script,
|
|
batch file, or whatever on the PATH that invokes
|
|
$WXWIN/utils/wxPython/distrib/build.py to help simplify matters
|
|
somewhat. For example, on my win32 system I have a file named
|
|
build.bat in a directory on the PATH that contains:
|
|
|
|
python %WXWIN%/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
|
|
|
|
|
|
5. Change into the $(WXWIN)/utils/wxPython/src directory.
|
|
|
|
|
|
6. If you don't use SWIG, or have a new enough version installed, you
|
|
may have to update the timestamps of the files it generates so the
|
|
make utility won't think they are out of date and try to run SWIG
|
|
to update them. The standard touch utility can do this for you:
|
|
|
|
touch gtk/*.cpp gtk/*.py
|
|
|
|
|
|
7. Type "build -b" to build wxPython and "build -i" to install it.
|
|
|
|
The build.py script actually generates a Makefile based on what it
|
|
finds on your system and information found in the build.cfg file.
|
|
If you have troubles building or you want it built or installed in
|
|
a different way, take a look at the docstring in build.py. You may
|
|
be able to override configuration options in a file named
|
|
build.local. For example, you can set a new TARGETDIR (the
|
|
installation directory) just by creating a file named build.local
|
|
in your wxPython source directory and assign a value to it, like
|
|
this:
|
|
|
|
TARGETDIR = "/usr/local/lib/python1.5/site-packages/wxPython"
|
|
|
|
The build.local file is executed as Python code so you can do very
|
|
creative things there if you need to.
|
|
|
|
|
|
8. To build and install the add-on modules, change to the appropriate
|
|
directory under $WXWIN/utils/wxPython/modules and run the build
|
|
utility again.
|
|
|
|
|
|
9. Change to the $WXWIN/utils/wxPython/demo directory.
|
|
|
|
|
|
10. Try executing the demo program. For example:
|
|
|
|
python demo.py
|
|
|
|
To run it without requiring a console on win32, you can use the
|
|
pythonw.exe version of Python either from the command line or from
|
|
a shortcut.
|