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. If you do
-you'll want to have version 1.1-883 of SWIG and you'll need to change
-a flag in the setup.py script as described below.
+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.
+If you need to modify the *.i files for wxPython then change to this
+directory and run:
+
+ configure
+ make
+
+(Do not run "make install" as wxswig is run in-place.) You'll then
+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 usually use RedHat Linux when working on the wxGTK version of
-wxPython, but I occasionally build and test on Solaris and I hope to
-be able to add some other platforms soon. The compiler I use is
-whatever comes with the current version of RedHat I am using. I find
-that there are less portability problems with the RPMs if I don't try
-using the latest and greatest compilers all the time. On the other
-platforms I usually stick with as recent a version of GCC that I can
-find pre-built for that platform.
-
Okay, now on the the fun stuff...
-------------------------------
A. You can find the sources and RPMs for wxGTK at
- ftp://wesley.informatik.uni-freiburg.de/pub/linux/wxxt/source/, or
- just follow the download links from http://wxwindows.org/. You can
- also check out a current snapshot of the sources from the CVS
- server. (Some information about annonymous CVS access is at
- http://wxwindows.org/cvs.htm.) 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 testing done. You can decide which
- method is best for you.
+ http://wxwindows.org/, just follow the download links from the
+ nevigation panel. You can also check out a current snapshot of the
+ sources from the CVS server. (Some information about annonymous
+ CVS access is at http://wxwindows.org/cvs.htm.) 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.
B. You'll usually want to use a version of wxGTK that has the same
version number as the wxPython sources you are using. (Another
special debugging code in wxWindows by defining the __WXDEBUG__
macro. You'll get some extra asserts, failure logging, etc.
+ To make a static library and not make a shared library, use the
+ --disable-shared and --enable-static flags.
+
+ NOTE: It has been discovered that some pre-built distributions of
+ Python are built with options that can cause incompatibilities
+ between wxPython and wxGTK. Typically these are things like large
+ file support on the platforms that have it. This causes some basic
+ types, like off_t, to be typedef'd differently causing the C++
+ method signatures to be incompatible and giving link errors. The
+ way to fix this is to activate these same settings in the wxGTK
+ build, usually by looking at the flags and options used in
+ compiling wxPython that are different from the options used on
+ wxGTK compiles. For example, on SuSE doing the following before
+ running wxGTK's configure seems to take care of it:
+
+ export CFLAGS="-D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT"
+ export CXXFLAGS=$CFLAGS
+
+
E. Now just compile and install. You need to use GNU make, so if your
system has something else get GNU make and build and install it and
use it instead of your system's default make command.
it doesn't, there doesn't seem to be a way to override the values
that Distutils uses without hacking either Distutils itself, or
Python's Makefile. (Complain to the distutils-sig about this
- please.) For example, on my Solaris system I had to edit
+ please.) For example, on a Solaris system I had to edit
/usr/local/lib/python1.5/config/Makefile and replace
LDSHARED=ld -G
In my case on Solaris wxPython applications would core dump on
exit. The core file indicated that the fault happened after
- _exit() was called and the run-time was trying to execute cleanup
- code. After relinking the Python executable the problem went away.
- To build Python to link with the C++ linker do this:
+ _exit() was called and the run-time library was trying to execute
+ cleanup code. After relinking the Python executable the problem
+ went away. To build Python to link with the C++ linker do this:
cd Python-2.0 # wherever the root of the source tree is
rm python # in case it's still there from an old build
projects / wxWidgets.git / blobdiff