+++ /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