]>
Commit | Line | Data |
---|---|---|
1 | <?xml version="1.0" encoding="iso-8859-1" ?> | |
2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | |
3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> | |
4 | <head> | |
5 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> | |
6 | <meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" /> | |
7 | <title>Building wxPython 2.5 for Development and Testing</title> | |
8 | <link rel="stylesheet" href="default.css" type="text/css" /> | |
9 | </head> | |
10 | <body> | |
11 | <div class="document" id="building-wxpython-2-5-for-development-and-testing"> | |
12 | <h1 class="title">Building wxPython 2.5 for Development and Testing</h1> | |
13 | <p>This file describes how I build wxWidgets and wxPython while doing | |
14 | development and testing, and is meant to help other people that want | |
15 | to do the same thing. I'll assume that you are using either a CVS | |
16 | snapshot from <a class="reference" href="http://wxWidgets.org/snapshots/">http://wxWidgets.org/snapshots/</a>, a checkout from CVS, or | |
17 | one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that | |
18 | you know your way around your system, the compiler, etc. and most | |
19 | importantly, that you know what you are doing! ;-)</p> | |
20 | <p>If you want to also install the version of wxPython you build to be in | |
21 | your site-packages dir and be your default version of wxPython, then a | |
22 | few additional steps are needed, and you may want to use slightly | |
23 | different options. See INSTALL.txt for more details. If you only use | |
24 | the instructions in this BUILD.txt file then you will end up with a | |
25 | separate installation of wxPython and you can switch back and forth | |
26 | between this and the release version that you may already have | |
27 | installed.</p> | |
28 | <p>If you want to make changes to any of the <tt class="literal"><span class="pre">*.i</span></tt> files, (SWIG interface | |
29 | definition files,) or to regenerate the extension sources or renamer | |
30 | modules, then you will need an up to date version of SWIG. Either get | |
31 | and build the current CVS version, or version 1.3.20, and then apply | |
32 | the patches in wxPython/SWIG. See the README.txt in that dir for | |
33 | details about each patch and also info about those that may already | |
34 | have been applied to the SWIG sources. If you install this build of | |
35 | SWIG to a location that is not on the PATH (so it doesn't interfere | |
36 | with an existing SWIG install for example) then you can set a setup.py | |
37 | command-line variable named SWIG to be the full path name of the | |
38 | executable and the wxPython build will use it. See below for an | |
39 | example.</p> | |
40 | <div class="section" id="building-on-unix-like-systems-e-g-linux-and-os-x"> | |
41 | <h1><a name="building-on-unix-like-systems-e-g-linux-and-os-x">Building on Unix-like Systems (e.g. Linux and OS X)</a></h1> | |
42 | <p>These platforms are built almost the same way while in development | |
43 | so I'll combine the descriptions about their build process here. | |
44 | First we will build wxWidgets and install it to an out of the way | |
45 | place, then do the same for wxPython.</p> | |
46 | <ol class="arabic"> | |
47 | <li><p class="first">Create a build directory in the main wxWidgets dir, and configure | |
48 | wxWidgets. If you want to have multiple builds with different | |
49 | configure options, just use different subdirectories. I normally | |
50 | put the configure command in a script named ".configure" in each | |
51 | build dir so I can easily blow away everything in the build dir and | |
52 | rerun the script without having to remember the options I used | |
53 | before:</p> | |
54 | <pre class="literal-block"> | |
55 | mkdir bld | |
56 | cd bld | |
57 | ../configure --prefix=/opt/wx/2.5 \ | |
58 | --with-gtk \ | |
59 | --with-opengl \ | |
60 | --disable-monolithic \ | |
61 | --enable-debug \ | |
62 | --enable-geometry \ | |
63 | --enable-sound --with-sdl \ | |
64 | --enable-display \ | |
65 | </pre> | |
66 | <p>On OS X of course you'll want to use --with-mac instead of | |
67 | --with-gtk. For GTK2 and unicode add:</p> | |
68 | <pre class="literal-block"> | |
69 | --enable-gtk2 \ | |
70 | --enable-unicode \ | |
71 | </pre> | |
72 | <p>Notice that I used a prefix of /opt/wx/2.5. You can use whatever | |
73 | path you want, such as a path in your HOME dir or even one of the | |
74 | standard prefix paths such as /usr or /usr/local if you like, but | |
75 | using /opt this way lets me easily have multiple versions and ports | |
76 | of wxWidgets "installed" and makes it easy to switch between them, | |
77 | without impacting any versions of wxWidgets that may have been | |
78 | installed via an RPM or whatever. For the rest of the steps below | |
79 | be sure to also substitute "/opt/wx/2.5" with whatever prefix you | |
80 | choose for your build.</p> | |
81 | <p>If you want to use the image and zlib libraries included with | |
82 | wxWidgets instead of those already installed on your system, (for | |
83 | example, to reduce dependencies on 3rd party libraries) then you | |
84 | can add these flags to the configure command:</p> | |
85 | <pre class="literal-block"> | |
86 | --with-libjpeg=builtin \ | |
87 | --with-libpng=builtin \ | |
88 | --with-libtiff=builtin \ | |
89 | --with-zlib=builtin \ | |
90 | </pre> | |
91 | </li> | |
92 | <li><p class="first">To build and install wxWidgets you could just use the "make" | |
93 | command but there are other libraries besides the main wxWidgets | |
94 | libs that also need to be built so again I make a script to do it | |
95 | all for me so I don't forget anything. This time it is called | |
96 | ".make" (I use the leading ". so when I do <tt class="literal"><span class="pre">rm</span> <span class="pre">-r</span> <span class="pre">*</span></tt> in my build | |
97 | dir I don't lose my scripts too.) This is what it looks like:</p> | |
98 | <pre class="literal-block"> | |
99 | make $* \ | |
100 | && make -C contrib/src/gizmos $* \ | |
101 | && make -C contrib/src/ogl CXXFLAGS="-DwxUSE_DEPRECATED=0" $* \ | |
102 | && make -C contrib/src/stc $* \ | |
103 | && make -C contrib/src/xrc $* | |
104 | </pre> | |
105 | <p>So you just use .make as if it where make, but don't forget to set | |
106 | the execute bit on .make first!:</p> | |
107 | <pre class="literal-block"> | |
108 | .make | |
109 | .make install | |
110 | </pre> | |
111 | <p>When it's done you should have an installed set of files under | |
112 | /opt/wx/2.5 containing just wxWidgets. Now to use this version of | |
113 | wxWidgets you just need to add /opt/wx/2.5/bin to the PATH and set | |
114 | LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.5/lib.</p> | |
115 | </li> | |
116 | <li><p class="first">I also have a script to help me build wxPython and it is checked in | |
117 | to the CVS as wxWidgets/wxPython/b, but probably don't want to use | |
118 | it as it's very cryptic and expects that you want to run SWIG, so | |
119 | if you don't have the latest patched up version of SWIG then you'll | |
120 | probably get stuck. So I'll just give the raw commands instead.</p> | |
121 | <p>We're not going to install the development version of wxPython with | |
122 | these commands, so it won't impact your already installed version | |
123 | of the latest release. You'll be able test with this version when | |
124 | you want to, and use the installed release version the rest of the | |
125 | time. If do want to install the development verison please read | |
126 | INSTALL.txt.</p> | |
127 | <p>If you have more than one version of Python on your system then be | |
128 | sure to use the version of Python that you want to use when running | |
129 | wxPython programs to run the setup.py commands below. I'll be | |
130 | using python2.3.</p> | |
131 | <p>Make sure that the first wx-config found on the PATH is the one you | |
132 | installed above, and then change to the wxWidgets/wxPython dir and | |
133 | run the this command:</p> | |
134 | <pre class="literal-block"> | |
135 | cd wxPython | |
136 | python2.3 setup.py build_ext --inplace --debug | |
137 | </pre> | |
138 | <p>If your new wx-config script is not on the PATH, or there is some | |
139 | other version of it found first, then you can add this to the | |
140 | command line to ensure your new one is used instead:</p> | |
141 | <pre class="literal-block"> | |
142 | WX_CONFIG=/opt/wx/2.5/bin/wx-config | |
143 | </pre> | |
144 | <p>If you are building with GTK2 then add the following flags to the | |
145 | command line:</p> | |
146 | <pre class="literal-block"> | |
147 | WXPORT=gtk2 UNICODE=1 | |
148 | </pre> | |
149 | <p>If you are wanting to have the source files regenerated with swig, | |
150 | then you need to turn on the USE_SWIG flag and optionally tell it | |
151 | where to find the new swig executable, so add these flags:</p> | |
152 | <pre class="literal-block"> | |
153 | USE_SWIG=1 SWIG=/opt/swig/bin/swig | |
154 | </pre> | |
155 | <p>If you get errors about wxGLCanvas or being unable to find libGLU | |
156 | or something like that then you can add BUILD_GLCANVAS=0 to the | |
157 | setup.py command line to disable the building of the glcanvas | |
158 | module.</p> | |
159 | <p>When the setup.py command is done you should have fully populated | |
160 | wxPython and wx packages locally in wxWidgets/wxPython/wxPython and | |
161 | .../wx, with all the extension modules (<tt class="literal"><span class="pre">*.so</span></tt> files) located in the | |
162 | wx package.</p> | |
163 | </li> | |
164 | <li><p class="first">To run code with the development verison of wxPython, just set the | |
165 | PYTHONPATH to the wxPython dir in the CVS tree. For example:</p> | |
166 | <pre class="literal-block"> | |
167 | export LD_LIBRARY=/opt/wx/2.5/lib | |
168 | export PYTHONPATH=/myprojects/wxWidgets/wxPython | |
169 | cd /myprojects/wxWidgets/wxPython/demo | |
170 | python2.3 demo.py | |
171 | </pre> | |
172 | <p>OS X NOTE: You need to use "pythonw" on the command line to run | |
173 | wxPython applications. This version of the Python executable is | |
174 | part of the Python Framework and is allowed to interact with the | |
175 | display. You can also double click on a .py or a .pyw file from | |
176 | the finder (assuming that PythonLauncher is still associated with | |
177 | these file extensions) and it will launch the Framework version of | |
178 | Python for you. For information about creating Applicaiton Bundles | |
179 | of your wxPython apps please see the wiki and the mail lists.</p> | |
180 | <p>SOLARIS NOTE: If you get unresolved symbol errors when importing | |
181 | wxPython and you are running on Solaris and building with gcc, then | |
182 | you may be able to work around the problem by uncommenting a bit of | |
183 | code in setup.py and building again. Look for 'SunOS' in setup.py | |
184 | and uncomment the block containing it. The problem is that Sun's ld | |
185 | does not automatically add libgcc to the link step.</p> | |
186 | </li> | |
187 | </ol> | |
188 | </div> | |
189 | <div class="section" id="building-on-windows"> | |
190 | <h1><a name="building-on-windows">Building on Windows</a></h1> | |
191 | <p>The Windows builds currently require the use of Microsoft Visual C++. | |
192 | Theoretically, other compilers (such as mingw32 or the Borland | |
193 | compilers) can also be used but I've never done the work to make that | |
194 | happen. If you want to try that then first you'll want to find out if | |
195 | there are any tricks that have to be done to make Python extension | |
196 | modules using that compiler, and then make a few changes to setup.py | |
197 | to accomodate that. (And send the patches to me.) If you plan on | |
198 | using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also | |
199 | have to build Python and any other extension modules that you use with | |
200 | that compiler because a different version of the C runtime likbrary is | |
201 | used. The Python executable that comes from PythonLabs and the | |
202 | wxPython extensions that I distribute are built with MSVC 6 with all | |
203 | the Service Packs applied.</p> | |
204 | <p>If you want to build a debugable version of wxWidgets and wxPython you | |
205 | will need to have also built a debug version of Python and any other | |
206 | extension modules you need to use. You can tell if you have them | |
207 | already if there is a _d in the file names, for example python_d.exe | |
208 | or python23_d.dll. If you don't need to trace through the C/C++ parts | |
209 | of the code with the debugger then building the normal (or hybrid) | |
210 | version is fine, and you can use the regular python executables with | |
211 | it.</p> | |
212 | <p>Just like the unix versions I also use some scripts to help me build | |
213 | wxWidgets, but I use some non-standard stuff to do it. So if you want | |
214 | to use them too you'll need to get a copy or 4DOS or 4NT from | |
215 | <a class="reference" href="http://www.jpsoft.com/">http://www.jpsoft.com/</a> and also a copy of unix-like cat and sed | |
216 | programs. You can also do by hand what my scripts are doing, but | |
217 | there are a lof steps involved and I won't be going into details | |
218 | here. There is a copy of my build scripts in wxWidgetswxPythondistribmsw</p> | |
219 | <ol class="arabic"> | |
220 | <li><p class="first">Set an environment variable to the root of the wxWidgets source | |
221 | tree:</p> | |
222 | <pre class="literal-block"> | |
223 | set WXWIN=e:\projects\wxWidgets | |
224 | </pre> | |
225 | </li> | |
226 | <li><p class="first">Copy setup0.h to setup.h</p> | |
227 | <blockquote> | |
228 | <p>cd %WXWIN%includewxmsw | |
229 | copy setup0.h setup.h</p> | |
230 | </blockquote> | |
231 | </li> | |
232 | <li><p class="first">Edit %WXWIN%includewxmswsetup.h and change a few settings. | |
233 | Some of them are changed by my build scripts depending on the type | |
234 | of build (debug/hybrid, unicode/ansi). I change a few of the other | |
235 | defaults to have these values:</p> | |
236 | <pre class="literal-block"> | |
237 | wxDIALOG_UNIT_COMPATIBILITY 0 | |
238 | wxUSE_DEBUG_CONTEXT 1 | |
239 | wxUSE_MEMORY_TRACING 1 | |
240 | wxUSE_DIALUP_MANAGER 0 | |
241 | wxUSE_GLCANVAS 1 | |
242 | wxUSE_POSTSCRIPT 1 | |
243 | wxUSE_AFM_FOR_POSTSCRIPT 0 | |
244 | wxUSE_DISPLAY 1 | |
245 | </pre> | |
246 | </li> | |
247 | <li><p class="first">Make a %WXWIN%BIN directory and add it to the PATH. My build | |
248 | scripts will copy the wxWidgets DLLs there.</p> | |
249 | </li> | |
250 | <li><p class="first">Change to the %WXWIN%buildmsw directory and copy my build scripts | |
251 | there.</p> | |
252 | </li> | |
253 | <li><p class="first">Use the .make.btm command to build wxWidgets. It needs one | |
254 | command-line parameter which controls what kind of build(s) to do. | |
255 | Use one of the following:</p> | |
256 | <pre class="literal-block"> | |
257 | debug Build debug version | |
258 | hybrid Build hybrid version | |
259 | both Both debug and hybrid | |
260 | debug-uni Build a debug unicode library | |
261 | hybrid-uni Hybrid unicode (see the pattern yet? ;-) | |
262 | both-uni and finally both unicode libraries | |
263 | </pre> | |
264 | <p>For example:</p> | |
265 | <pre class="literal-block"> | |
266 | .make hybrid | |
267 | ||
268 | You can also pass additional command line parameters as needed and | |
269 | they will all be passed on to the nmake commands, for example to | |
270 | clean up the build:: | |
271 | ||
272 | .make hybrid clean | |
273 | </pre> | |
274 | </li> | |
275 | <li><p class="first">When that is done it will have built the main wxWidgets DLLs and | |
276 | also some of the contribs DLLs. There should be a ton of DLLs in | |
277 | %WXDIR%bin and lots of lib files and other stuff in | |
278 | %WXDIR%libvc_dll.</p> | |
279 | </li> | |
280 | <li><p class="first">Building wxPython on Windows is very similar to doing it for the | |
281 | unix systems. We're not going to install the development version | |
282 | of wxPython with these commands, so it won't impact your already | |
283 | installed version of the latest release. You'll be able to test | |
284 | with this version when you want to, and use the installed release | |
285 | version the rest of the time. If you ever do want to install the | |
286 | development verison please refer to INSTALL.txt.</p> | |
287 | <p>Change to the wxWidgetswxPython dir and run the this command, | |
288 | makeing sure that you use the version of python that you want to | |
289 | build for (if you have more than one on your system):</p> | |
290 | <pre class="literal-block"> | |
291 | cd %WXWIN%\wxPython | |
292 | python setup.py build_ext --inplace | |
293 | </pre> | |
294 | <p>If you are wanting to have the source files regenerated with swig, | |
295 | then you need to turn on the USE_SWIG flag and optionally tell it | |
296 | where to find the new swig executable, so add these flags:</p> | |
297 | <pre class="literal-block"> | |
298 | USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe | |
299 | </pre> | |
300 | <p>If you built a Unicode version of wxWidgets and want to also build | |
301 | the Unicode version of wxPython then add this flag:</p> | |
302 | <pre class="literal-block"> | |
303 | UNICODE=1 | |
304 | </pre> | |
305 | <p>If you have a debug version of Python and wxWidgets and want to | |
306 | build a debug version of wxPython too, add the --debug flag to the | |
307 | command line. You should then end up with a set of <tt class="literal"><span class="pre">*_d.pyd</span></tt> | |
308 | files in the wx package and you'll have to run <tt class="literal"><span class="pre">python_d.exe</span></tt> to | |
309 | use them. The debug and hybrid(release) versions can coexist.</p> | |
310 | <p>When the setup.py command is done you should have fully populated | |
311 | wxPython and wx packages locally in wxWidgets/wxPython/wxPython and | |
312 | wxWidgets/wxPython/wx, with all the extension modules (<tt class="literal"><span class="pre">*.pyd</span></tt> | |
313 | files) located in the wx package.</p> | |
314 | </li> | |
315 | <li><p class="first">To run code with the development verison of wxPython, just set the | |
316 | PYTHONPATH to the wxPython dir in the CVS tree. For example:</p> | |
317 | <pre class="literal-block"> | |
318 | set PYTHONPATH=e:\projects\wxWidgets\wxPython | |
319 | cd e:\projects\wxWidgets\wxPython | |
320 | python demo.py | |
321 | </pre> | |
322 | </li> | |
323 | </ol> | |
324 | </div> | |
325 | </div> | |
326 | <hr class="footer" /> | |
327 | <div class="footer"> | |
328 | Generated on: 2004-03-12 19:55 UTC. | |
329 | </div> | |
330 | </body> | |
331 | </html> |