| 1 | Building wxPython on Unix or Unix-like Systems |
| 2 | ---------------------------------------------- |
| 3 | |
| 4 | The basic steps for building wxPython for Unix or Unix-like systems |
| 5 | are: |
| 6 | |
| 7 | 1. Compile and/or install glib and gtk+ |
| 8 | 2. Compile and/or install wxGTK |
| 9 | 3. Compile and install wxPython |
| 10 | |
| 11 | We'll go into more detail of each of these steps below, but first a |
| 12 | few bits of background information on tools. |
| 13 | |
| 14 | I use a tool called SWIG (http://www.swig.org) to help generate the |
| 15 | C++ sources used in the wxPython extension module. However you don't |
| 16 | need to have SWIG unless you want to modify the *.i files. If you do |
| 17 | you'll want to have version 1.1-883 of SWIG and you'll need to apply |
| 18 | the patches and updates in wxPython/SWIG and rebuild it. Then you'll |
| 19 | need to change a flag in the setup.py script as described below so the |
| 20 | wxPython build process will use SWIG if needed. |
| 21 | |
| 22 | I use the new Python Distutils tool to build wxPython. It is included |
| 23 | with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then |
| 24 | you'll need to download and install Distutils 1.0 from |
| 25 | http://www.python.org/sigs/distutils-sig/ |
| 26 | |
| 27 | I usually use RedHat Linux when working on the wxGTK version of |
| 28 | wxPython, but I occasionally build and test on Solaris and I hope to |
| 29 | be able to add some other platforms soon. The compiler I use is |
| 30 | whatever comes with the current version of RedHat I am using. I find |
| 31 | that there are less portability problems with the RPMs if I don't try |
| 32 | using the latest and greatest compilers all the time. On the other |
| 33 | platforms I usually stick with as recent a version of GCC that I can |
| 34 | find pre-built for that platform. |
| 35 | |
| 36 | Okay, now on the the fun stuff... |
| 37 | |
| 38 | |
| 39 | 1. Compile and/or install glib and gtk+ |
| 40 | --------------------------------------- |
| 41 | |
| 42 | A. First of all, check and see if you've already got glib/gtk+ on your |
| 43 | system, all the Linux distributions I know of come with it, at |
| 44 | least as an option. Look for libglib.* and libgtk.* in your system's |
| 45 | standard library directories. You'll also need the headers and |
| 46 | config scripts in order to build things that use glib/gtk. Try |
| 47 | running gtk-config: |
| 48 | |
| 49 | gtk-config --version |
| 50 | |
| 51 | If you have version 1.2.5 or better then you're all set. You can |
| 52 | skip to step #2. |
| 53 | |
| 54 | B. If your system has a binary package mechanism, (RPMs, debs, |
| 55 | whatever...) check and see if binaries for glib abd gtk+ are |
| 56 | available. Be sure to get the runtime library package as well as |
| 57 | the development package, if they are separate. Install them with |
| 58 | your package tool, and skip to step #2. |
| 59 | |
| 60 | C. If all else fails, you can get the source code for glib and gtk+ at |
| 61 | http://www.gtk.org/. Fetch the latest of each in the 1.2.x |
| 62 | series. Compile and install each of them like this: |
| 63 | |
| 64 | gzip -d [package].tar.gz | tar xvf - |
| 65 | cd [package] |
| 66 | ./configure |
| 67 | make |
| 68 | make install |
| 69 | |
| 70 | The last step will probably have to be done as root. Also, if your |
| 71 | system needs anything done to update the dynamic loader for shared |
| 72 | libraries, (such as running ldconfig on Linux) then do it after |
| 73 | each library is installed. |
| 74 | |
| 75 | |
| 76 | |
| 77 | 2. Compile and/or install wxGTK |
| 78 | ------------------------------- |
| 79 | |
| 80 | A. You can find the sources and RPMs for wxGTK at |
| 81 | ftp://wesley.informatik.uni-freiburg.de/pub/linux/wxxt/source/, or |
| 82 | just follow the download links from http://wxwindows.org/. You can |
| 83 | also check out a current snapshot of the sources from the CVS |
| 84 | server. (Some information about annonymous CVS access is at |
| 85 | http://wxwindows.org/cvs.htm.) The advantage of using CVS is that |
| 86 | you can easily update as soon as the developers check in new |
| 87 | sources or fixes. The advantage of using a released version is |
| 88 | that it usually has had more testing done. You can decide which |
| 89 | method is best for you. |
| 90 | |
| 91 | B. You'll usually want to use a version of wxGTK that has the same |
| 92 | version number as the wxPython sources you are using. (Another |
| 93 | advantage of using CVS is that you'll get both at the same time.) |
| 94 | |
| 95 | C. If using the RPMs be sure to get both the wxGTK and wxGTK-devel |
| 96 | RPMs (at a minimum) and then install them as root. |
| 97 | |
| 98 | rpm -Uhv wxGTK-2.2.2-0.i386.rpm wxGTK-devel-2.2.2-0.i386.rpm |
| 99 | |
| 100 | D. If using the sources (either from the tarball or from CVS) then |
| 101 | configure it like this: |
| 102 | |
| 103 | cd wxWindows # or whatever your top-level directory is called |
| 104 | mkdir build |
| 105 | cd build |
| 106 | ../configure --with-gtk |
| 107 | |
| 108 | There are gobs and gobs of options for the configure script, run |
| 109 | ../configure --help to see them all. I'll describe some that I find |
| 110 | useful here. |
| 111 | |
| 112 | If you have OpenGL or compatible libraries installed, then add the |
| 113 | --with-opengl flag. |
| 114 | |
| 115 | If you are on Solaris and are using a recent version of GCC, then |
| 116 | you'll probably want to add the --enable-permissive flag so the |
| 117 | compiler won't barf on your broken X11 header files. |
| 118 | |
| 119 | To make a debugging version of wxGTK, add the --enable-debug flag. |
| 120 | This sets the -g flag for the compiler and also activates some |
| 121 | special debugging code in wxWindows by defining the __WXDEBUG__ |
| 122 | macro. You'll get some extra asserts, failure logging, etc. |
| 123 | |
| 124 | To make a static library and not make a shared library, use the |
| 125 | --disable-shared and --enable-static flags. |
| 126 | |
| 127 | E. Now just compile and install. You need to use GNU make, so if your |
| 128 | system has something else get GNU make and build and install it and |
| 129 | use it instead of your system's default make command. |
| 130 | |
| 131 | make |
| 132 | make install |
| 133 | |
| 134 | The last step will probably have to be done as root. Also, if your |
| 135 | system needs anything done to update the dynamic loader for shared |
| 136 | libraries, (such as running ldconfig on Linux) then do it now. |
| 137 | |
| 138 | F. You can test your build by changing to one of the directories under |
| 139 | build/samples or build/demos, running make and then running the |
| 140 | executable that is built. |
| 141 | |
| 142 | |
| 143 | |
| 144 | 3. Compile and install wxPython |
| 145 | ------------------------------- |
| 146 | |
| 147 | A. You have the same options (and same advantages/disadvantages) for |
| 148 | getting the wxPython source, either a released snapshot or from |
| 149 | CVS. The released version file is named wxPython-[version].tar.gz |
| 150 | and is available at http://wxpython.org/download.php. If you want |
| 151 | to use CVS you'll find wxPython in the wxWindows CVS tree (see |
| 152 | above) in the wxWindows/wxPython directory. |
| 153 | |
| 154 | B. As mentioned previouslly, wxPython is built with the standard |
| 155 | Python Distutils tool. If you are using Python 2.0 or later you |
| 156 | are all set, otherwise you need to download and install Distutils |
| 157 | 1.0 from http://www.python.org/sigs/distutils-sig/. |
| 158 | |
| 159 | On Unix systems Distutils figures out what commands and flags to |
| 160 | use for the compiler and linker by looking in the Makefile that was |
| 161 | used to build Python itself. Most of the time this works okay. If |
| 162 | it doesn't, there doesn't seem to be a way to override the values |
| 163 | that Distutils uses without hacking either Distutils itself, or |
| 164 | Python's Makefile. (Complain to the distutils-sig about this |
| 165 | please.) For example, on my Solaris system I had to edit |
| 166 | /usr/local/lib/python1.5/config/Makefile and replace |
| 167 | |
| 168 | LDSHARED=ld -G |
| 169 | |
| 170 | with |
| 171 | |
| 172 | LDSHARED=gcc -G |
| 173 | |
| 174 | This particular problem has been fixed in Python 1.6 and beyond, |
| 175 | but there may be similar issues on other platforms. |
| 176 | |
| 177 | While we're on the subject of how Python was built... Since |
| 178 | wxPython is a C++ extension some platforms and/or compilers will |
| 179 | require that the Python executable was linked with the C++ linker |
| 180 | in order for everything to work correctly. If you build and |
| 181 | install Python yourself then this is easy to take care of, |
| 182 | otherwise you may have to mess with binary packages or bribe your |
| 183 | system administrator... |
| 184 | |
| 185 | In my case on Solaris wxPython applications would core dump on |
| 186 | exit. The core file indicated that the fault happened after |
| 187 | _exit() was called and the run-time was trying to execute cleanup |
| 188 | code. After relinking the Python executable the problem went away. |
| 189 | To build Python to link with the C++ linker do this: |
| 190 | |
| 191 | cd Python-2.0 # wherever the root of the source tree is |
| 192 | rm python # in case it's still there from an old build |
| 193 | make LINKCC=g++ # or whatever your C++ command is |
| 194 | make install |
| 195 | |
| 196 | |
| 197 | C. Change to the root wxPython directory and look at the setup.py |
| 198 | file. This is the script that configures and defines all the |
| 199 | information that Distutils needs to build wxPython. There are some |
| 200 | options near the begining of the script that you may want or need |
| 201 | to change based on your system and what options you have selected |
| 202 | up to this point, (sources from tar.gz or from CVS, etc.) You can |
| 203 | either change these flags directly in setup.py or supply them on |
| 204 | the command-line. |
| 205 | |
| 206 | BUILD_GLCANVAS Set to zero if you don't want to build the |
| 207 | Open GL canvas extension module. If you don't |
| 208 | have OpenGL or compatible libraries then you'll |
| 209 | need to set this to zero. |
| 210 | |
| 211 | BUILD_OGL Set to zero if you don't want to build the |
| 212 | Object Graphics Library extension module. |
| 213 | |
| 214 | BUILD_STC Set to zero if you don't want to build the |
| 215 | wxStyledTextCtrl (the Scintilla wrapper) |
| 216 | extension module. |
| 217 | |
| 218 | USE_SWIG If you have edited any of the *.i files you |
| 219 | will need to set this flag to non-zero so SWIG |
| 220 | will be executed to regenerate the wrapper C++ |
| 221 | and shadow python files. |
| 222 | |
| 223 | IN_CVS_TREE If you are using the CVS version of the |
| 224 | wxWindows and wxPython sources then you will |
| 225 | need to set this flag to non-zero. This is |
| 226 | needed because some source files from the |
| 227 | wxWindows tree are copied to be under the |
| 228 | wxPython tree in order to keep Distutils happy. |
| 229 | With this flag set then setup.py will |
| 230 | automatically keep these copied sources up to |
| 231 | date if the original version is ever updated. |
| 232 | If you are using the tar.gz version of the |
| 233 | Python sources then these copied sources are |
| 234 | already present in your source tree. |
| 235 | |
| 236 | |
| 237 | D. To build and install wxPython you simply need to execute the |
| 238 | setup.py script. If you have more than one version of Python |
| 239 | installed, be sure to execute setup.py with the version you want to |
| 240 | build wxPython for. Depending on the permissions on your |
| 241 | site-packages directory you may need to be root to run the install |
| 242 | command. |
| 243 | |
| 244 | python setup.py build |
| 245 | python setup.py install |
| 246 | |
| 247 | E. At this point you should be able to change into the wxPython/demo |
| 248 | directory and run the demo: |
| 249 | |
| 250 | python demo.py |
| 251 | |
| 252 | F. If you would like to make a test build that doesn't overwrite the |
| 253 | installed version of wxPython you can do so with this command |
| 254 | instead of the install command above: |
| 255 | |
| 256 | python setup.py build_ext --inplace |
| 257 | |
| 258 | This will build the wxPython package in the local wxPython |
| 259 | directory instead of installing it under your Python installation. |
| 260 | To run using this test version just add the base wxPython source |
| 261 | directory to the PYTHONPATH: |
| 262 | |
| 263 | export PYTHONPATH=~/projects/wxWindows/wxPython |
| 264 | # or whatever is required for your shell |
| 265 | cd ~/projects/wxWindows/wxPython/demo |
| 266 | python demo.py |
| 267 | |
| 268 | |
| 269 | That's all folks! |
| 270 | |
| 271 | |
| 272 | ----------------- |
| 273 | robin@alldunn.com |