--- /dev/null
+Building wxPython on Unix or Unix-like Systems
+----------------------------------------------
+
+NOTE: You should probably look at the ../ README.1st.txt file for
+directions for how to build wxPython the "new way." This files
+describes the "old way" to build on unix-like systems. The difference
+is very simple: The new way uses a private copy of wxGTK while the
+old way uses either an existing wxGTK that may be installed and used
+by other apps, or you can build a wxGTK that will be accessable by
+other apps.
+
+
+NOTE 2: 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 and older version of SWIG
+that are 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 you will need to
+build wxswig. Change to the .../wxPython/wxSWIG 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/
+
+Okay, now on the the fun stuff...
+
+
+1. Compile and/or install glib and gtk+
+---------------------------------------
+
+A. First of all, check and see if you've already got glib/gtk+ on your
+ system, all the Linux distributions I know of come with it, at
+ least as an option. Look for libglib.* and libgtk.* in your system's
+ standard library directories. You'll also need the headers and
+ config scripts in order to build things that use glib/gtk. Try
+ running gtk-config:
+
+ gtk-config --version
+
+ If you have version 1.2.7 or better then you're all set. Otherwise
+ either get the pacakges for your unix distribution and install them
+ or get the sources from www.gtk.org and build and install them.
+
+ The best version to get is the latest 1.2.x release as the
+ wxWindows support for GTK 2.x is still beta-level. (Most tings
+ work great though, and it looks real nice.)
+
+
+
+2. Compile and/or install wxGTK
+-------------------------------
+
+A. You can find the sources and RPMs for wxGTK at
+ http://wxwindows.org/, just follow the download links from the
+ navigation panel.
+
+ Source code for wxGTK is now included with the wxPythonSrc tarball,
+ and is the recommended way to get released wxGTK source code if you
+ plan on building both.
+
+ 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
+ advantage of using wxPythonSrc or CVS is that you'll get both at
+ the same time.)
+
+
+C. If using the RPMs be sure to get both the wxGTK and wxGTK-devel
+ RPMs (at a minimum) and then install them as root.
+
+ rpm -Uhv wxGTK-2.2.2-0.i386.rpm wxGTK-devel-2.2.2-0.i386.rpm
+
+
+D. If using the sources (either from the tarball or from CVS) then
+ configure it like this:
+
+ cd wxWindows # or whatever your top-level directory is called
+ mkdir build
+ cd build
+ ../configure --with-gtk --enable-geometry
+
+ There are gobs and gobs of options for the configure script, run
+ ../configure --help to see them all. I'll describe some that I find
+ useful here.
+
+ If you have OpenGL or compatible libraries installed, then add the
+ --with-opengl flag.
+
+ If you are on Solaris and are using a recent version of GCC, then
+ you'll probably want to add the --enable-permissive flag so the
+ compiler won't barf on your broken X11 header files.
+
+ To make a debugging version of wxGTK, add the --enable-debug flag.
+ This sets the -g flag for the compiler and also activates some
+ special debugging code in wxWindows by defining the __WXDEBUG__
+ macro. You'll get some extra asserts, failure logging, etc.
+
+ If you are using GTK 2.x then you'll want to add --enable-gtk2 and
+ probably also --enable-unicode.
+
+
+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.
+
+ make
+ make install
+
+ The last step will probably have to be done as root. Also, if your
+ system needs anything done to update the dynamic loader for shared
+ libraries, (such as running ldconfig on Linux) then do it now.
+
+
+F. You can test your build by changing to one of the directories under
+ build/samples or build/demos, running make and then running the
+ executable that is built.
+
+
+
+3. Compile and install wxPython
+-------------------------------
+
+A. You have the same options (and same advantages/disadvantages) for
+ getting the wxPython source, either a released snapshot or from
+ CVS. The released version file is named wxPythonSrc-[version].tar.gz
+ and is available at http://wxpython.org/download.php. If you want
+ to use CVS you'll find wxPython in the wxWindows CVS tree (see
+ above) in the wxWindows/wxPython directory.
+
+
+B. wxPython is built with the standard Python Distutils tool and
+ currently includes it's own snapshot of the latest version of
+ distutils which can also be used with previous versions of Python
+
+ On Unix systems Distutils figures out what commands and flags to
+ use for the compiler and linker by looking in the Makefile that was
+ used to build Python itself. Most of the time this works okay. If
+ 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. (NOTE: This has been changed with the
+ distutilsincluded with Python 2.3 but I havn't yet looked into how
+ best to utilize this in wxPython...)
+
+ While we're on the subject of how Python was built... Since
+ wxPython is a C++ extension some platforms and/or compilers will
+ require that the Python executable was linked with the C++ linker
+ in order for everything to work correctly. If you build and
+ install Python yourself then this is easy to take care of,
+ otherwise you may have to mess with binary packages or bribe your
+ system administrator...
+
+ 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 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
+ make LINKCC=g++ # or whatever your C++ command is
+ make install
+
+ I recently built Python 2.1.3 and Python 2.2.1 on Solaris and did
+ not have to resort to this workaround so apparently things are
+ getting better there. I will leave this note here though in case
+ there are similar issues elsewhere. However I did run into a
+ Python build issue that affects the wxPython build when attempting
+ to use SunCC instead of GNU gcc. See the note below titled
+ "Building with non-GNU compilers" if you are interested.
+
+
+C. 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 your system and what options you have selected
+ up to this point, (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. If you don't
+ have OpenGL or compatible libraries then you'll
+ need to set this to zero.
+
+ 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.
+
+
+D. 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 the permissions on your
+ site-packages directory you may need to be root to run the install
+ command.
+
+ python setup.py build install
+
+ If you need to change any of the build flags that can also be done
+ on the setup.py command line, like this:
+
+ python setup.py BUILD_GLCANVAS=0 build install
+
+ If you are using GTK 2.x then you'll want to add these flags:
+
+ python setup.py WXPORT=gtk2 UNICODE=1 build install
+
+ 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.
+
+
+E. At this point you should be able to change into the wxPython/demo
+ directory and run the demo:
+
+ python demo.py
+
+
+F. If you would like to make a test build that doesn't overwrite any
+ installed version of wxPython you can do so with this command
+ instead of the install command above:
+
+ python setup.py 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:
+
+ export PYTHONPATH=~/projects/wxWindows/wxPython
+ # or whatever is required for your shell
+ cd ~/projects/wxWindows/wxPython/demo
+ python demo.py
+
+
+
+4. Building with non-GNU compilers
+----------------------------------
+
+As mentioned above Python's distutils uses whatever compiler Python
+was compiled with to compile extension modules. It also appears that
+distutils assumes that this compiler can compile C or C++ sources as
+distutils makes no differentiation between the two. For builds using
+GNU gcc and a few other compilers this is not an issue as they will
+determine the type of source from the file extension. For SunCC (and
+probably other compilers that came from cfront) it won't work as the C
+compiler (cc) is totally separate from the C++ compiler (CC). This
+causes distutils to attempt to compile the wxPython sources with the C
+compiler, which won't work.
+
+There may be better ways to get around this, but here is the
+workaround I devised. I created a script that will execute either cc
+or CC based on the file extension given to it. If Python uses this
+script for its compiler then it will also be used by extensions built
+with distutils and everybody will be more or less happy. Here is a
+copy of the script I used. It was a fairly quick rush job so there
+are probably issues with it but it worked for me.
+
+ #!/bin/bash
+ #--------------------------------------------------------------
+ # Try to determine type of file being compiled and then
+ # launch cc for C sources or CC for C++.
+ #
+
+ args=$@
+ is_C=
+
+ for arg in $args; do
+
+ # is the arg a file that exists?
+ if [ -e $arg ]; then
+
+ # does it end in ".c"?
+ if [ "${arg:${#arg}-2}" == ".c" ]; then
+ is_C=yes
+ fi
+ fi
+ done
+
+ # if the flag wasn't set then assume C++ and execute CC,
+ # otherwise execute cc.
+ if [ -z $is_C ]; then
+ exec CC -w $@
+ else
+ exec cc -w $@
+ fi
+ #--------------------------------------------------------------
+
+I called it pycc, put it in ${prefix}/bin and set its execute
+permission bit.
+
+The next step is to configure and build Python such that it uses pycc
+as it's compiler. You can do that by setting CC in your environment
+before running configure, like this in bash:
+
+ export CC=pycc
+ configure
+
+After making and installing Python with this configuration you should
+be able to build wxPython as described in the steps above.
+
+
+
+-----------------
+robin@alldunn.com
projects / wxWidgets.git / blobdiff