wxWidgets/wxPython/BUILD.txt
Bryan Petty 3ca6a5f046 second merge of the 2.2 branch (RL)
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@7973 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2000-08-08 06:11:51 +00:00

169 lines
6.2 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/Etc.
For *nix systems I run configure with these flags:
--with-gtk
--with-libjpeg
--with-opengl
--without-odbc
--enable-unicode=no
--enable-threads=yes
--enable-socket=yes
--enable-static=no
--enable-shared=yes
--disable-std_iostreams
--enable-newgrid
You can use whatever flags you want, but these work for me. If you
want debug libraries, then you should add the "--enable-debug
--enable-mem_tracing" flags. I reccommend creating an empty build
directory, and then running make and configure from there. This
makes it easy to experiment with different configure options
without losing old builds.
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 1
wxUSE_GLOBAL_MEMORY_OPERATORS 0
wxUSE_LIBTIFF 1
wxUSE_GLCANVAS 1
I also change these:
wxUSE_DIALUP_MANAGER 0
wxUSE_DYNLIB_CLASS 0
wxUSE_DOC_VIEW_ARCHITECTURE 0
wxUSE_MDI_ARCHITECTURE 0
wxUSE_PLOT 0
wxUSE_POSTSCRIPT_ARCHITECTURE_IN_MSW 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 the win32 platform you should be sure to set an environment
variable named WXWIN to be the path to the top of the wxWindows
source tree.
3. If you are working from a copy of the code retrieved from CVS, then
you will find wxPython in $WXWIN/wxPython. If you are working from
the tar.gz or .zip files then you will probably want to unpack
wxPython in the $WXWIN 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.15/src"
If your wxPython sources are not under $WXWIN then you'll need to
adjust the remainder of these instructions accordingly.
4. At this point you may want to make an alias, symlink, script,
batch file, or whatever on the PATH that invokes
$WXWIN/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%/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
5. Change into the $(WXWIN)/wxPython/src directory.
6. If you don't use SWIG, or don't 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
or
touch msw\*.cpp msw\*.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 doc-string 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/wxPython/contrib and run the build utility
again.
9. Change to the $WXWIN/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.