]>
Commit | Line | Data |
---|---|---|
c368d904 RD |
1 | Building wxPython on Win32 |
2 | -------------------------- | |
3 | ||
4 | ||
5 | Building wxPython for use on win32 systems is a fairly simple process | |
6 | consisting of just a few steps. However depending on where you get | |
7 | your sources from and what your desired end result is, there are | |
8 | several permutations of those steps. At a high level the basic steps | |
9 | are: | |
10 | ||
11 | 1. Get the wxWindows sources | |
12 | 2. Build the wxWindows DLL | |
13 | 3. Get the wxPython sources | |
14 | 4. Build and Install wxPython | |
15 | ||
16 | We'll go into more detail of each of these steps below, but first a | |
17 | few bits of background information on tools. | |
18 | ||
19 | I use a tool called SWIG (http://www.swig.org) to help generate the | |
20 | C++ sources used in the wxPython extension module. However you don't | |
21 | need to have SWIG unless you want to modify the *.i files. If you do | |
22 | you'll want to have version 1.1-883 of SWIG and you'll need to change | |
23 | a flag in the setup.py script as described below. | |
24 | ||
25 | I use the new Python Distutils tool to build wxPython. It is included | |
26 | with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then | |
27 | you'll need to download and install Distutils 1.0 from | |
28 | http://www.python.org/sigs/distutils-sig/ | |
29 | ||
30 | I use Microsoft Visual C++ 6.0 (5.0 with the service packs should work | |
31 | also) to compile the wxPython C++ sources. Since I am using Distutils | |
32 | it should be easier now to build with other win32 compilers such as | |
33 | the free mingw32 or Borland compilers, but I havn't tried them yet. | |
34 | If anybody wants to try it I'll take any required patches for the | |
35 | setup script and for these instructions. | |
36 | ||
37 | And now on to the fun stuff... | |
38 | ||
39 | ||
40 | ||
41 | 1. Get the wxWindows sources | |
42 | ---------------------------- | |
43 | ||
44 | A. There are a few possible ways to get sources for wxWindows. You | |
45 | can download a released version from http://wxwindows.org/ or you | |
46 | can get current development sources from the CVS server. (Some | |
47 | information about annonymous CVS access is at | |
48 | http://wxwindows.org/cvs.htm.) The advantage of using CVS is that | |
49 | you can easily update as soon as the developers check in new | |
50 | sources or fixes. The advantage of using a released version is | |
51 | that it usually has had more testing done. You can decide which | |
52 | method is best for you. | |
53 | ||
54 | B. You'll usually want to use wxWindows sources that have the same | |
55 | version number as the wxPython sources you are using. (Another | |
56 | advantage of using CVS is that you'll get both at the same time.) | |
57 | ||
58 | NOTE: There probably isn't going to be an official 2.2.2 release | |
59 | for wxMSW so I have taken a snapshot of my workspace and made it | |
60 | available at http://alldunn.com/wxPython/dist/others/ | |
61 | ||
62 | C. Once you get the sources be sure to put them in a path without a | |
63 | space in it (i.e., NOT c:\Program Files\wx) and set an environment | |
64 | variable named WXWIN to this directory. For example: | |
65 | ||
66 | mkdir \wx2 | |
67 | cd \wx2 | |
68 | unzip wxMSW-2.2.2.zip | |
69 | set WXWIN=c:\wx2 | |
70 | ||
71 | You'll probably want to add that last line to your autoexec.bat or | |
72 | System Properties depending on the type of system you are on. | |
73 | ||
74 | D. Change to the wx2\include\wx\msw directory and copy setup0.h to | |
75 | setup.h and then edit setup.h. This is how you control which parts | |
76 | of wxWindows are compiled into or left out of the build, simply by | |
77 | turning options on or off. At a minimum you should set the | |
78 | following: | |
79 | ||
80 | wxUSE_NEW_GRID 1 | |
81 | wxUSE_GLOBAL_MEMORY_OPERATORS 0 | |
82 | wxUSE_LIBTIFF 1 | |
83 | wxUSE_GLCANVAS 1 | |
84 | wxDIALOG_UNIT_COMPATIBILITY 0 | |
85 | ||
86 | I also turn off the following as they are not currently used in | |
87 | wxPython. There are probably others that can be turned off to | |
88 | help save space, but I havn't investigated all the potential | |
89 | configurations yet. Please note that wxPython doesn't (yet) check | |
90 | these flags for its own build, so if you turn off something that | |
91 | wxPython expects then you'll get link errors later on. | |
92 | ||
93 | wxUSE_DIALUP_MANAGER 0 | |
94 | wxUSE_DYNLIB_CLASS 0 | |
95 | wxUSE_DOC_VIEW_ARCHITECTURE 0 | |
96 | wxUSE_MDI_ARCHITECTURE 0 | |
97 | wxUSE_PLOT 0 | |
98 | wxUSE_POSTSCRIPT_ARCHITECTURE_IN_MSW 0 | |
99 | ||
100 | ||
101 | ||
102 | ||
103 | 2. Build the wxWindows DLL | |
104 | --------------------------- | |
105 | ||
106 | A. Although MSVC project files are provided I always use the makefiles | |
107 | to build wxWindows because by default the flags are compatible with | |
108 | Python, (and I make sure they stay that way.) You would have to | |
109 | edit the project files a bit to make it work otherwise. | |
110 | ||
111 | B. There are three different types of wxWindows DLLs that can be | |
112 | produced by the VC makefile simply by providing a flag on the nmake | |
113 | command-line, I call the three types DEBUG, FINAL, and HYBRID. | |
114 | (The last one is brand new, you'll need my version of the 2.2.2 | |
115 | sources to get the HYBRID capability.) Here are some more details: | |
116 | ||
117 | DEBUG Specified with "FINAL=0" and produces a DLL named | |
118 | wx[version]d.dll. This DLL is compiled with full | |
119 | debugging information and with the __WXDEBUG__ set which | |
120 | enables some debugging-only code in wxWindows such as | |
121 | assertions and failure log messages. The /MDd flag is | |
122 | used which means that it is linked with the debugging | |
123 | version of the C runtime library and also that you must | |
124 | use the debugging version of Python, (python_d.exe and | |
125 | pythonXX_d.dll) which also means that all extensions | |
126 | loaded by Python should also have the _d in the name. | |
127 | With this option you can use the MSVC debugger to trace | |
128 | though the Python interpreter, as well as the code for the | |
129 | wxPython extension and the wxWindows DLL. | |
130 | ||
131 | FINAL Specified with "FINAL=1" and produces a DLL named | |
132 | wx[version].dll. This DLL is compiled with optimizations | |
133 | turned on and without debugging information and without | |
134 | __WXDEBUG__. The /MD flag is used which means that you | |
135 | can use this version with the standard python.exe. This | |
136 | is the version that I use when making the binary installer | |
137 | for win32. | |
138 | ||
139 | HYBRID Specified with "FINAL=hybrid" and produces a DLL named | |
140 | wx[version]h.dll. This DLL is almost the same as the | |
141 | DEBUG version except the /MD flag is used which means that | |
142 | you can use the standard python.exe but you still get the | |
143 | debugging info and the __WXDEBUG__ code enabled. With the | |
144 | debugger you can trace through the the code for the | |
145 | wxPython extension and the wxWindows DLL, but not the | |
146 | Python interpreter. You might use this version when you | |
147 | want to deploy a wxPython app with the __WXDEBUG__ code | |
148 | enabled. I use this mode most of the time during | |
149 | development simply because it's easier than having to | |
150 | remember to type python_d all the time. | |
151 | ||
152 | Since different DLL names and object file directories are used you | |
153 | can build all three types if you like. | |
154 | ||
155 | C. Change to the wx2\src\msw directory and type the following command, | |
156 | using the value for FINAL that you want: | |
157 | ||
158 | nmake -f makefile.vc dll pch USE_GLCANVAS=1 FINAL=hybrid | |
159 | ||
160 | Your machine will then crunch away for possibly a long time, | |
161 | depending on your hardware, and when it's done you should have a | |
162 | DLL and some library files in \wx2\lib. | |
163 | ||
164 | D. You'll either need to add \wx2\lib to the PATH or copy the DLL file | |
165 | to a directory already on the PATH so the DLL can be found at runtime. | |
166 | ||
167 | E. You can test your build by changing to one of the directories under | |
168 | \wx2\samples or \wx2\demos and typing (using the right FINAL flag): | |
169 | ||
170 | nmake -f makefile.vc FINAL=hybrid WXUSINGDLL=1 | |
171 | ||
172 | and then executing the resulting .exe file. | |
173 | ||
174 | ||
175 | ||
176 | 3. Get the wxPython sources | |
177 | --------------------------- | |
178 | ||
179 | A. You have the same options (and same advantages/disadvantages) for | |
180 | getting the wxPython source, either a released snapshot or from | |
181 | CVS. The released version file is named wxPython-[version].tar.gz | |
182 | and is available at http://wxpython.org/download.php. You can use | |
183 | WinZip to unpack it if you don't have tar and gzip. If you want to | |
184 | use CVS you'll find wxPython in the wxWindows CVS tree (see above) | |
185 | in the wxWindows/wxPython directory. | |
186 | ||
187 | ||
188 | ||
189 | 4. Build and Install wxPython | |
190 | ----------------------------- | |
191 | ||
192 | A. As mentioned previouslly, wxPython is built with the standard | |
193 | Python Distutils tool. If you are using Python 2.0c1 or later you | |
194 | are all set, otherwise you need to download and install Distutils | |
195 | 1.0 from http://www.python.org/sigs/distutils-sig/. | |
196 | ||
197 | B. 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 what options you have selected up to this point, | |
202 | (type of DLL built, 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. | |
208 | ||
209 | BUILD_OGL Set to zero if you don't want to build the | |
210 | Object Graphics Library extension module. | |
211 | ||
212 | BUILD_STC Set to zero if you don't want to build the | |
213 | wxStyledTextCtrl (the Scintilla wrapper) | |
214 | extension module. | |
215 | ||
216 | USE_SWIG If you have edited any of the *.i files you | |
217 | will need to set this flag to non-zero so SWIG | |
218 | will be executed to regenerate the wrapper C++ | |
219 | and shadow python files. | |
220 | ||
221 | IN_CVS_TREE If you are using the CVS version of the | |
222 | wxWindows and wxPython sources then you will | |
223 | need to set this flag to non-zero. This is | |
224 | needed because some source files from the | |
225 | wxWindows tree are copied to be under the | |
226 | wxPython tree in order to keep Distutils happy. | |
227 | With this flag set then setup.py will | |
228 | automatically keep these copied sources up to | |
229 | date if the original version is ever updated. | |
230 | If you are using the tar.gz version of the | |
231 | Python sources then these copied sources are | |
232 | already present in your source tree. | |
233 | ||
234 | ||
235 | C. To build and install wxPython you simply need to execute the | |
236 | setup.py script. If you have more than one version of Python | |
237 | installed, be sure to execute setup.py with the version you want to | |
238 | build wxPython for. | |
239 | ||
240 | Depending on what kind of wxWindows DLL you built there are | |
241 | different command-line parameters you'll want to pass to setup (in | |
242 | addition to possibly one or more of the above): | |
243 | ||
244 | FINAL: python setup.py install | |
245 | ||
246 | DEBUG: python setup.py build --debug install | |
247 | ||
248 | HYBRID: python setup.py HYBRID=1 install | |
249 | ||
250 | ||
251 | D. At this point you should be able to change into the wxPython\demo | |
252 | directory and run the demo: | |
253 | ||
254 | python demo.py | |
255 | ||
256 | E. If you would like to make a test build that doesn't overwrite the | |
257 | installed version of wxPython you can do so with one of these | |
258 | commands instead of the install command above: | |
259 | ||
260 | FINAL: python setup.py build_ext --inplace | |
261 | ||
262 | DEBUG: python setup.py build_ext --debug --inplace | |
263 | ||
264 | HYBRID: python setup.py HYBRID=1 build_ext --inplace | |
265 | ||
266 | This will build the wxPython package in the local wxPython | |
267 | directory instead of installing it under your Python installation. | |
268 | To run using this test version just add the base wxPython source | |
269 | directory to the PYTHONPATH: | |
270 | ||
271 | set PYTHONPATH=c:\wx2\wxPython | |
272 | cd c:\wx2\wxPython\demo | |
273 | python demo.py | |
274 | ||
275 | ||
276 | That's all folks! | |
277 | ||
278 | ||
279 | ----------------- | |
280 | robin@alldunn.com | |
281 |