|
1 Building Python using VC++ 9.0 |
|
2 ------------------------------ |
|
3 |
|
4 This directory is used to build Python for Win32 and x64 platforms, e.g. |
|
5 Windows 2000, XP, Vista and Windows Server 2008. In order to build 32-bit |
|
6 debug and release executables, Microsoft Visual C++ 2008 Express Edition is |
|
7 required at the very least. In order to build 64-bit debug and release |
|
8 executables, Visual Studio 2008 Standard Edition is required at the very |
|
9 least. In order to build all of the above, as well as generate release builds |
|
10 that make use of Profile Guided Optimisation (PG0), Visual Studio 2008 |
|
11 Professional Edition is required at the very least. The official Python |
|
12 releases are built with this version of Visual Studio. |
|
13 |
|
14 For other Windows platforms and compilers, see ../PC/readme.txt. |
|
15 |
|
16 All you need to do is open the workspace "pcbuild.sln" in Visual Studio, |
|
17 select the desired combination of configuration and platform and eventually |
|
18 build the solution. Unless you are going to debug a problem in the core or |
|
19 you are going to create an optimized build you want to select "Release" as |
|
20 configuration. |
|
21 |
|
22 The PCbuild directory is compatible with all versions of Visual Studio from |
|
23 VS C++ Express Edition over the standard edition up to the professional |
|
24 edition. However the express edition does not support features like solution |
|
25 folders or profile guided optimization (PGO). The missing bits and pieces |
|
26 won't stop you from building Python. |
|
27 |
|
28 The solution is configured to build the projects in the correct order. "Build |
|
29 Solution" or F7 takes care of dependencies except for x64 builds. To make |
|
30 cross compiling x64 builds on a 32bit OS possible the x64 builds require a |
|
31 32bit version of Python. |
|
32 |
|
33 NOTE: |
|
34 You probably don't want to build most of the other subprojects, unless |
|
35 you're building an entire Python distribution from scratch, or |
|
36 specifically making changes to the subsystems they implement, or are |
|
37 running a Python core buildbot test slave; see SUBPROJECTS below) |
|
38 |
|
39 When using the Debug setting, the output files have a _d added to |
|
40 their name: python30_d.dll, python_d.exe, parser_d.pyd, and so on. Both |
|
41 the build and rt batch files accept a -d option for debug builds. |
|
42 |
|
43 The 32bit builds end up in the solution folder PCbuild while the x64 builds |
|
44 land in the amd64 subfolder. The PGI and PGO builds for profile guided |
|
45 optimization end up in their own folders, too. |
|
46 |
|
47 Legacy support |
|
48 -------------- |
|
49 |
|
50 You can find build directories for older versions of Visual Studio and |
|
51 Visual C++ in the PC directory. The legacy build directories are no longer |
|
52 actively maintained and may not work out of the box. |
|
53 |
|
54 PC/VC6/ |
|
55 Visual C++ 6.0 |
|
56 PC/VS7.1/ |
|
57 Visual Studio 2003 (7.1) |
|
58 PCbuild8/ |
|
59 Visual Studio 2005 (8.0) |
|
60 |
|
61 |
|
62 C RUNTIME |
|
63 --------- |
|
64 |
|
65 Visual Studio 2008 uses version 9 of the C runtime (MSVCRT9). The executables |
|
66 are linked to a CRT "side by side" assembly which must be present on the target |
|
67 machine. This is avalible under the VC/Redist folder of your visual studio |
|
68 distribution. On XP and later operating systems that support |
|
69 side-by-side assemblies it is not enough to have the msvcrt90.dll present, |
|
70 it has to be there as a whole assembly, that is, a folder with the .dll |
|
71 and a .manifest. Also, a check is made for the correct version. |
|
72 Therefore, one should distribute this assembly with the dlls, and keep |
|
73 it in the same directory. For compatibility with older systems, one should |
|
74 also set the PATH to this directory so that the dll can be found. |
|
75 For more info, see the Readme in the VC/Redist folder. |
|
76 |
|
77 SUBPROJECTS |
|
78 ----------- |
|
79 These subprojects should build out of the box. Subprojects other than the |
|
80 main ones (pythoncore, python, pythonw) generally build a DLL (renamed to |
|
81 .pyd) from a specific module so that users don't have to load the code |
|
82 supporting that module unless they import the module. |
|
83 |
|
84 pythoncore |
|
85 .dll and .lib |
|
86 python |
|
87 .exe |
|
88 pythonw |
|
89 pythonw.exe, a variant of python.exe that doesn't pop up a DOS box |
|
90 _socket |
|
91 socketmodule.c |
|
92 _testcapi |
|
93 tests of the Python C API, run via Lib/test/test_capi.py, and |
|
94 implemented by module Modules/_testcapimodule.c |
|
95 pyexpat |
|
96 Python wrapper for accelerated XML parsing, which incorporates stable |
|
97 code from the Expat project: http://sourceforge.net/projects/expat/ |
|
98 select |
|
99 selectmodule.c |
|
100 unicodedata |
|
101 large tables of Unicode data |
|
102 winsound |
|
103 play sounds (typically .wav files) under Windows |
|
104 |
|
105 Python-controlled subprojects that wrap external projects: |
|
106 _bsddb |
|
107 Wraps Berkeley DB 4.7.25, which is currently built by _bsddb.vcproj. |
|
108 project (see below). |
|
109 _sqlite3 |
|
110 Wraps SQLite 3.5.9, which is currently built by sqlite3.vcproj (see below). |
|
111 _tkinter |
|
112 Wraps the Tk windowing system. Unlike _bsddb and _sqlite3, there's no |
|
113 corresponding tcltk.vcproj-type project that builds Tcl/Tk from vcproj's |
|
114 within our pcbuild.sln, which means this module expects to find a |
|
115 pre-built Tcl/Tk in either ..\..\tcltk for 32-bit or ..\..\tcltk64 for |
|
116 64-bit (relative to this directory). See below for instructions to build |
|
117 Tcl/Tk. |
|
118 bz2 |
|
119 Python wrapper for the libbz2 compression library. Homepage |
|
120 http://sources.redhat.com/bzip2/ |
|
121 Download the source from the python.org copy into the dist |
|
122 directory: |
|
123 |
|
124 svn export http://svn.python.org/projects/external/bzip2-1.0.5 |
|
125 |
|
126 ** NOTE: if you use the Tools\buildbot\external(-amd64).bat approach for |
|
127 obtaining external sources then you don't need to manually get the source |
|
128 above via subversion. ** |
|
129 |
|
130 A custom pre-link step in the bz2 project settings should manage to |
|
131 build bzip2-1.0.5\libbz2.lib by magic before bz2.pyd (or bz2_d.pyd) is |
|
132 linked in PCbuild\. |
|
133 However, the bz2 project is not smart enough to remove anything under |
|
134 bzip2-1.0.5\ when you do a clean, so if you want to rebuild bzip2.lib |
|
135 you need to clean up bzip2-1.0.5\ by hand. |
|
136 |
|
137 All of this managed to build libbz2.lib in |
|
138 bzip2-1.0.5\$platform-$configuration\, which the Python project links in. |
|
139 |
|
140 _ssl |
|
141 Python wrapper for the secure sockets library. |
|
142 |
|
143 Get the source code through |
|
144 |
|
145 svn export http://svn.python.org/projects/external/openssl-0.9.8g |
|
146 |
|
147 ** NOTE: if you use the Tools\buildbot\external(-amd64).bat approach for |
|
148 obtaining external sources then you don't need to manually get the source |
|
149 above via subversion. ** |
|
150 |
|
151 Alternatively, get the latest version from http://www.openssl.org. |
|
152 You can (theoretically) use any version of OpenSSL you like - the |
|
153 build process will automatically select the latest version. |
|
154 |
|
155 You must install the NASM assembler from |
|
156 http://nasm.sf.net |
|
157 for x86 builds. Put nasmw.exe anywhere in your PATH. |
|
158 |
|
159 You can also install ActivePerl from |
|
160 http://www.activestate.com/Products/ActivePerl/ |
|
161 if you like to use the official sources instead of the files from |
|
162 python's subversion repository. The svn version contains pre-build |
|
163 makefiles and assembly files. |
|
164 |
|
165 The build process makes sure that no patented algorithms are included. |
|
166 For now RC5, MDC2 and IDEA are excluded from the build. You may have |
|
167 to manually remove $(OBJ_D)\i_*.obj from ms\nt.mak if the build process |
|
168 complains about missing files or forbidden IDEA. Again the files provided |
|
169 in the subversion repository are already fixed. |
|
170 |
|
171 The MSVC project simply invokes PCBuild/build_ssl.py to perform |
|
172 the build. This Python script locates and builds your OpenSSL |
|
173 installation, then invokes a simple makefile to build the final .pyd. |
|
174 |
|
175 build_ssl.py attempts to catch the most common errors (such as not |
|
176 being able to find OpenSSL sources, or not being able to find a Perl |
|
177 that works with OpenSSL) and give a reasonable error message. |
|
178 If you have a problem that doesn't seem to be handled correctly |
|
179 (eg, you know you have ActivePerl but we can't find it), please take |
|
180 a peek at build_ssl.py and suggest patches. Note that build_ssl.py |
|
181 should be able to be run directly from the command-line. |
|
182 |
|
183 build_ssl.py/MSVC isn't clever enough to clean OpenSSL - you must do |
|
184 this by hand. |
|
185 |
|
186 The subprojects above wrap external projects Python doesn't control, and as |
|
187 such, a little more work is required in order to download the relevant source |
|
188 files for each project before they can be built. The buildbots do this each |
|
189 time they're built, so the easiest approach is to run either external.bat or |
|
190 external-amd64.bat in the ..\Tools\buildbot directory from ..\, i.e.: |
|
191 |
|
192 C:\..\svn.python.org\projects\python\trunk\PCbuild>cd .. |
|
193 C:\..\svn.python.org\projects\python\trunk>Tools\buildbot\external.bat |
|
194 |
|
195 This extracts all the external subprojects from http://svn.python.org/external |
|
196 via Subversion (so you'll need an svn.exe on your PATH) and places them in |
|
197 ..\.. (relative to this directory). The external(-amd64).bat scripts will |
|
198 also build a debug build of Tcl/Tk; there aren't any equivalent batch files |
|
199 for building release versions of Tcl/Tk lying around in the Tools\buildbot |
|
200 directory. If you need to build a release version of Tcl/Tk it isn't hard |
|
201 though, take a look at the relevant external(-amd64).bat file and find the |
|
202 two nmake lines, then call each one without the 'DEBUG=1' parameter, i.e.: |
|
203 |
|
204 The external-amd64.bat file contains this for tcl: |
|
205 nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install |
|
206 |
|
207 So for a release build, you'd call it as: |
|
208 nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install |
|
209 |
|
210 XXX Should we compile with OPTS=threads? |
|
211 XXX Our installer copies a lot of stuff out of the Tcl/Tk install |
|
212 XXX directory. Is all of that really needed for Python use of Tcl/Tk? |
|
213 |
|
214 This will be cleaned up in the future; ideally Tcl/Tk will be brought into our |
|
215 pcbuild.sln as custom .vcproj files, just as we've recently done with the |
|
216 _bsddb.vcproj and sqlite3.vcproj files, which will remove the need for |
|
217 Tcl/Tk to be built separately via a batch file. |
|
218 |
|
219 XXX trent.nelson 02-Apr-08: |
|
220 Having the external subprojects in ..\.. relative to this directory is a |
|
221 bit of a nuisance when you're working on py3k and trunk in parallel and |
|
222 your directory layout mimics that of Python's subversion layout, e.g.: |
|
223 |
|
224 C:\..\svn.python.org\projects\python\trunk |
|
225 C:\..\svn.python.org\projects\python\branches\py3k |
|
226 C:\..\svn.python.org\projects\python\branches\release25-maint |
|
227 |
|
228 I'd like to change things so that external subprojects are fetched from |
|
229 ..\external instead of ..\.., then provide some helper scripts or batch |
|
230 files that would set up a new ..\external directory with svn checkouts of |
|
231 the relevant branches in http://svn.python.org/projects/external/, or |
|
232 alternatively, use junctions to link ..\external with a pre-existing |
|
233 externals directory being used by another branch. i.e. if I'm usually |
|
234 working on trunk (and have previously created trunk\external via the |
|
235 provided batch file), and want to do some work on py3k, I'd set up a |
|
236 junction as follows (using the directory structure above as an example): |
|
237 |
|
238 C:\..\python\trunk\external <- already exists and has built versions |
|
239 of the external subprojects |
|
240 |
|
241 C:\..\python\branches\py3k>linkd.exe external ..\..\trunk\external |
|
242 Link created at: external |
|
243 |
|
244 Only a slight tweak would be needed to the buildbots such that bots |
|
245 building trunk and py3k could make use of the same facility. (2.5.x |
|
246 builds need to be kept separate as they're using Visual Studio 7.1.) |
|
247 /XXX trent.nelson 02-Apr-08 |
|
248 |
|
249 Building for Itanium |
|
250 -------------------- |
|
251 |
|
252 NOTE: |
|
253 Official support for Itanium builds have been dropped from the build. Please |
|
254 contact us and provide patches if you are interested in Itanium builds. |
|
255 |
|
256 The project files support a ReleaseItanium configuration which creates |
|
257 Win64/Itanium binaries. For this to work, you need to install the Platform |
|
258 SDK, in particular the 64-bit support. This includes an Itanium compiler |
|
259 (future releases of the SDK likely include an AMD64 compiler as well). |
|
260 In addition, you need the Visual Studio plugin for external C compilers, |
|
261 from http://sf.net/projects/vsextcomp. The plugin will wrap cl.exe, to |
|
262 locate the proper target compiler, and convert compiler options |
|
263 accordingly. The project files require atleast version 0.9. |
|
264 |
|
265 Building for AMD64 |
|
266 ------------------ |
|
267 |
|
268 The build process for AMD64 / x64 is very similar to standard builds. You just |
|
269 have to set x64 as platform. In addition, the HOST_PYTHON environment variable |
|
270 must point to a Python interpreter (at least 2.4), to support cross-compilation. |
|
271 |
|
272 Building Python Using the free MS Toolkit Compiler |
|
273 -------------------------------------------------- |
|
274 |
|
275 Microsoft has withdrawn the free MS Toolkit Compiler, so this can no longer |
|
276 be considered a supported option. Instead you can use the free VS C++ Express |
|
277 Edition. |
|
278 |
|
279 Profile Guided Optimization |
|
280 --------------------------- |
|
281 |
|
282 The solution has two configurations for PGO. The PGInstrument |
|
283 configuration must be build first. The PGInstrument binaries are |
|
284 lniked against a profiling library and contain extra debug |
|
285 information. The PGUpdate configuration takes the profiling data and |
|
286 generates optimized binaries. |
|
287 |
|
288 The build_pgo.bat script automates the creation of optimized binaries. It |
|
289 creates the PGI files, runs the unit test suite or PyBench with the PGI |
|
290 python and finally creates the optimized files. |
|
291 |
|
292 http://msdn2.microsoft.com/en-us/library/e7k32f4k(VS.90).aspx |
|
293 |
|
294 Static library |
|
295 -------------- |
|
296 |
|
297 The solution has no configuration for static libraries. However it is easy |
|
298 it build a static library instead of a DLL. You simply have to set the |
|
299 "Configuration Type" to "Static Library (.lib)" and alter the preprocessor |
|
300 macro "Py_ENABLE_SHARED" to "Py_NO_ENABLE_SHARED". You may also have to |
|
301 change the "Runtime Library" from "Multi-threaded DLL (/MD)" to |
|
302 "Multi-threaded (/MT)". |
|
303 |
|
304 Visual Studio properties |
|
305 ------------------------ |
|
306 |
|
307 The PCbuild solution makes heavy use of Visual Studio property files |
|
308 (*.vsprops). The properties can be viewed and altered in the Property |
|
309 Manager (View -> Other Windows -> Property Manager). |
|
310 |
|
311 * debug (debug macro: _DEBUG) |
|
312 * pginstrument (PGO) |
|
313 * pgupdate (PGO) |
|
314 +-- pginstrument |
|
315 * pyd (python extension, release build) |
|
316 +-- release |
|
317 +-- pyproject |
|
318 * pyd_d (python extension, debug build) |
|
319 +-- debug |
|
320 +-- pyproject |
|
321 * pyproject (base settings for all projects, user macros like PyDllName) |
|
322 * release (release macro: NDEBUG) |
|
323 * x64 (AMD64 / x64 platform specific settings) |
|
324 |
|
325 The pyproject propertyfile defines _WIN32 and x64 defines _WIN64 and _M_X64 |
|
326 although the macros are set by the compiler, too. The GUI doesn't always know |
|
327 about the macros and confuse the user with false information. |
|
328 |
|
329 YOUR OWN EXTENSION DLLs |
|
330 ----------------------- |
|
331 |
|
332 If you want to create your own extension module DLL, there's an example |
|
333 with easy-to-follow instructions in ../PC/example/; read the file |
|
334 readme.txt there first. |