]>
Commit | Line | Data |
---|---|---|
c368d904 RD |
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 | |
9df61a29 RD |
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. | |
c368d904 RD |
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 | ||
185d7c3e RD |
124 | To make a static library and not make a shared library, use the |
125 | --disable-shared and --enable-static flags. | |
126 | ||
c368d904 RD |
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 |