traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update information pertaining to building external components, as well as notes on x64 builds. This file now accurately describes the build process as is; however, there's still a lot of room for improvement, especially with regards to how we build Tcl/Tk, Tix, and OpenSSL. Watch this space for further improvements.

This commit is contained in:
Trent Nelson 2008-04-02 15:01:00 +00:00
parent d0a91afa70
commit dbc114af0a
1 changed files with 95 additions and 134 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

229
PCbuild/readme.txt
View File

@ -1,10 +1,17 @@
Building Python using VC++ 9.0 Building Python using VC++ 9.0
------------------------------ ------------------------------
This directory is used to build Python for Win32 platforms, e.g. Windows This directory is used to build Python for Win32 and x64 platforms, e.g.
2000, XP and Vista. It requires Microsoft Visual C++ 9.0 Windows 2000, XP, Vista and Windows Server 2008. In order to build 32-bit
(a.k.a. Visual Studio .NET 2008). debug and release executables, Microsoft Visual C++ 2008 Express Edition is
(For other Windows platforms and compilers, see ../PC/readme.txt.) required at the very least. In order to build 64-bit debug and release
executables, Visual Studio 2008 Standard Edition is required at the very
least. In order to build all of the above, as well as generate release builds
that make use of Profile Guided Optimisation (PG0), Visual Studio 2008
Professional Edition is required at the very least. The official Python
releases are built with this version of Visual Studio.
For other Windows platforms and compilers, see ../PC/readme.txt.
All you need to do is open the workspace "pcbuild.sln" in Visual Studio, All you need to do is open the workspace "pcbuild.sln" in Visual Studio,
select the desired combination of configuration and platform and eventually select the desired combination of configuration and platform and eventually
@ -59,7 +66,7 @@ Visual Studio 2008 uses version 9 of the C runtime (MSVCRT9). The executables
are linked to a CRT "side by side" assembly which must be present on the target are linked to a CRT "side by side" assembly which must be present on the target
machine. This is avalible under the VC/Redist folder of your visual studio machine. This is avalible under the VC/Redist folder of your visual studio
distribution. On XP and later operating systems that support distribution. On XP and later operating systems that support
side-by-side assemblies it is not enough to have the msvcrt80.dll present, side-by-side assemblies it is not enough to have the msvcrt90.dll present,
it has to be there as a whole assembly, that is, a folder with the .dll it has to be there as a whole assembly, that is, a folder with the .dll
and a .manifest. Also, a check is made for the correct version. and a .manifest. Also, a check is made for the correct version.
Therefore, one should distribute this assembly with the dlls, and keep Therefore, one should distribute this assembly with the dlls, and keep
@ -95,79 +102,19 @@ unicodedata
winsound winsound
play sounds (typically .wav files) under Windows play sounds (typically .wav files) under Windows
The following subprojects will generally NOT build out of the box. They Python-controlled subprojects that wrap external projects:
wrap code Python doesn't control, and you'll need to download the base _bsddb
packages first and unpack them into siblings of PCbuilds's parent Wraps Berkeley DB 4.4.20, which is currently built by _bsddb44.vcproj.
directory; for example, if your PCbuild is ..\dist\py3k\PCbuild\, project (see below).
unpack into new subdirectories of ..\dist\. _sqlite3
Wraps SQLite 3.3.4, which is currently built by sqlite3.vcproj (see below).
_tkinter _tkinter
Python wrapper for the Tk windowing system. Requires building Wraps the Tk windowing system. Unlike _bsddb and _sqlite3, there's no
Tcl/Tk first. Following are instructions for Tcl/Tk 8.4.16. corresponding tcltk.vcproj-type project that builds Tcl/Tk from vcproj's
within our pcbuild.sln, which means this module expects to find a
NOTE: The 64 build builds must land in tcltk64 instead of tcltk. pre-built Tcl/Tk in either ..\..\tcltk for 32-bit or ..\..\tcltk64 for
64-bit (relative to this directory). See below for instructions to build
Get source Tcl/Tk.
----------
In the dist directory, run
svn export http://svn.python.org/projects/external/tcl8.4.16
svn export http://svn.python.org/projects/external/tk8.4.16
svn export http://svn.python.org/projects/external/tix-8.4.0
Build with build_tkinter.py
---------------------------
The PCbuild directory contains a Python script which automates all
steps. Run the script in a Visual Studio 2008 command prompt with
python build_tkinter.py Win32
Use x64 instead of Win32 for the x64 platform.
NOTE: Tcl/Tk 8.4 doesn't compile for x64.
Build Tcl first
---------------
Use "Start -> All Programs -> Microsoft Visual Studio 2008
-> Visual Studio Tools -> Visual Studio 2008 Command Prompt"
to get a shell window with the correct environment settings
cd dist\tcl8.4.16\win
nmake -f makefile.vc
nmake -f makefile.vc INSTALLDIR=..\..\tcltk install
XXX Should we compile with OPTS=threads?
Optional: run tests, via
nmake -f makefile.vc test
On WinXP Pro, wholly up to date as of 30-Aug-2004:
all.tcl: Total 10678 Passed 9969 Skipped 709 Failed 0
Sourced 129 Test Files.
Build Tk
--------
cd dist\tk8.4.16\win
nmake -f makefile.vc TCLDIR=..\..\tcl8.4.16
nmake -f makefile.vc TCLDIR=..\..\tcl8.4.16 INSTALLDIR=..\..\tcltk install
XXX Should we compile with OPTS=threads?
XXX Our installer copies a lot of stuff out of the Tcl/Tk install
XXX directory. Is all of that really needed for Python use of Tcl/Tk?
Optional: run tests, via
nmake -f makefile.vc TCLDIR=..\..\tcl8.4.16 test
On WinXP Pro, wholly up to date as of 30-Aug-2004:
all.tcl: Total 8420 Passed 6826 Skipped 1581 Failed 13
Sourced 91 Test Files.
Files with failing tests: canvImg.test scrollbar.test textWind.test winWm.test
Built Tix
---------
cd dist\tix-8.4.0\win
nmake -f python9.mak
nmake -f python9.mak install
bz2 bz2
Python wrapper for the libbz2 compression library. Homepage Python wrapper for the libbz2 compression library. Homepage
http://sources.redhat.com/bzip2/ http://sources.redhat.com/bzip2/
@ -176,6 +123,10 @@ bz2
svn export http://svn.python.org/projects/external/bzip2-1.0.3 svn export http://svn.python.org/projects/external/bzip2-1.0.3
** NOTE: if you use the Tools\buildbot\external(-amd64).bat approach for
obtaining external sources then you don't need to manually get the source
above via subversion. **
A custom pre-link step in the bz2 project settings should manage to A custom pre-link step in the bz2 project settings should manage to
build bzip2-1.0.3\libbz2.lib by magic before bz2.pyd (or bz2_d.pyd) is build bzip2-1.0.3\libbz2.lib by magic before bz2.pyd (or bz2_d.pyd) is
linked in PCbuild\. linked in PCbuild\.
@ -186,63 +137,6 @@ bz2
All of this managed to build libbz2.lib in All of this managed to build libbz2.lib in
bzip2-1.0.3\$platform-$configuration\, which the Python project links in. bzip2-1.0.3\$platform-$configuration\, which the Python project links in.
_bsddb
To use the version of bsddb that Python is built with by default, invoke
(in the dist directory)
svn export http://svn.python.org/projects/external/db-4.4.20
Next open the solution file db-4.4.20\build_win32\Berkeley_DB.sln with
Visual Studio and convert the projects to the new format. VS 2008
builds the necessary libraries in a pre-link step of _bsddb. You
have to add "$(VCInstallDir)vcpackages" to the search path first
(Tools -> Options -> Projects and Solutions -> VC++ Directories,
Platform: Win32, Show directories for: Executable files).
The _bsddb subprojects depends only on the db_static project of
Berkeley DB. You have to choose either "Release", "Release AMD64", "Debug"
or "Debug AMD64" as configuration. For the AND64 builds, you need to
create the "x64" platform first (in Solution Platforms\Configuration
Manager...)
Alternatively, if you want to start with the original sources,
go to Sleepycat's download page:
http://www.sleepycat.com/downloads/releasehistorybdb.html
and download version 4.4.20.
With or without strong cryptography? You can choose either with or
without strong cryptography, as per the instructions below. By
default, Python is built and distributed WITHOUT strong crypto.
Unpack the sources; if you downloaded the non-crypto version, rename
the directory from db-4.4.20.NC to db-4.4.20.
Now apply any patches that apply to your version.
Open
db-4.4.20\docs\ref\build_win\intro.html
and follow the "Windows->Building Berkeley DB with Visual C++ .NET"
instructions for building the Sleepycat
software. Note that Berkeley_DB.dsw is in the build_win32 subdirectory.
Build the "db_static" project, for "Release" mode.
To run extensive tests, pass "-u bsddb" to regrtest.py. test_bsddb3.py
is then enabled. Running in verbose mode may be helpful.
_sqlite3
Python wrapper for SQLite library.
Get the source code through
svn export http://svn.python.org/projects/external/sqlite-source-3.3.4
To use the extension module in a Python build tree, copy sqlite3.dll into
the PCbuild folder. The source directory in svn also contains a .def file
from the binary release of sqlite3.
_ssl _ssl
Python wrapper for the secure sockets library. Python wrapper for the secure sockets library.
@ -250,6 +144,10 @@ _ssl
svn export http://svn.python.org/projects/external/openssl-0.9.8g svn export http://svn.python.org/projects/external/openssl-0.9.8g
** NOTE: if you use the Tools\buildbot\external(-amd64).bat approach for
obtaining external sources then you don't need to manually get the source
above via subversion. **
Alternatively, get the latest version from http://www.openssl.org. Alternatively, get the latest version from http://www.openssl.org.
You can (theoretically) use any version of OpenSSL you like - the You can (theoretically) use any version of OpenSSL you like - the
build process will automatically select the latest version. build process will automatically select the latest version.
@ -285,6 +183,69 @@ _ssl
build_ssl.py/MSVC isn't clever enough to clean OpenSSL - you must do build_ssl.py/MSVC isn't clever enough to clean OpenSSL - you must do
this by hand. this by hand.
The subprojects above wrap external projects Python doesn't control, and as
such, a little more work is required in order to download the relevant source
files for each project before they can be built. The buildbots do this each
time they're built, so the easiest approach is to run either external.bat or
external-amd64.bat in the ..\Tools\buildbot directory from ..\, i.e.:
C:\..\svn.python.org\projects\python\trunk\PCbuild>cd ..
C:\..\svn.python.org\projects\python\trunk>Tools\buildbot\external.bat
This extracts all the external subprojects from http://svn.python.org/external
via Subversion (so you'll need an svn.exe on your PATH) and places them in
..\.. (relative to this directory). The external(-amd64).bat scripts will
also build a debug build of Tcl/Tk; there aren't any equivalent batch files
for building release versions of Tcl/Tk lying around in the Tools\buildbot
directory. If you need to build a release version of Tcl/Tk it isn't hard
though, take a look at the relevant external(-amd64).bat file and find the
two nmake lines, then call each one without the 'DEBUG=1' parameter, i.e.:
The external-amd64.bat file contains this for tcl:
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
So for a release build, you'd call it as:
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
XXX Should we compile with OPTS=threads?
XXX Our installer copies a lot of stuff out of the Tcl/Tk install
XXX directory. Is all of that really needed for Python use of Tcl/Tk?
This will be cleaned up in the future; ideally Tcl/Tk will be brought into our
pcbuild.sln as custom .vcproj files, just as we've recently done with the
_bsddb44.vcproj and sqlite3.vcproj files, which will remove the need for
Tcl/Tk to be built separately via a batch file.
XXX trent.nelson 02-Apr-08:
Having the external subprojects in ..\.. relative to this directory is a
bit of a nuisance when you're working on py3k and trunk in parallel and
your directory layout mimics that of Python's subversion layout, e.g.:
C:\..\svn.python.org\projects\python\trunk
C:\..\svn.python.org\projects\python\branches\py3k
C:\..\svn.python.org\projects\python\branches\release25-maint
I'd like to change things so that external subprojects are fetched from
..\external instead of ..\.., then provide some helper scripts or batch
files that would set up a new ..\external directory with svn checkouts of
the relevant branches in http://svn.python.org/projects/external/, or
alternatively, use junctions to link ..\external with a pre-existing
externals directory being used by another branch. i.e. if I'm usually
working on trunk (and have previously created trunk\external via the
provided batch file), and want to do some work on py3k, I'd set up a
junction as follows (using the directory structure above as an example):
C:\..\python\trunk\external <- already exists and has built versions
of the external subprojects
C:\..\python\branches\py3k>linkd.exe external ..\..\trunk\external
Link created at: external
Only a slight tweak would be needed to the buildbots such that bots
building trunk and py3k could make use of the same facility. (2.5.x
builds need to be kept separate as they're using Visual Studio 7.1.)
/XXX trent.nelson 02-Apr-08
Building for Itanium Building for Itanium
-------------------- --------------------