- Quick Start Guide
- -----------------
-
- 1. Install Microsoft Visual Studio 2015, any edition.
- 2. Install Subversion, and make sure 'svn.exe' is on your PATH.
- 3. Run "build.bat -e" to build Python in 32-bit Release configuration.
- 4. (Optional, but recommended) Run the test suite with "rt.bat -q".
-
-
- Building Python using Microsoft Visual C++
- ------------------------------------------
-
- This directory is used to build CPython for Microsoft Windows NT version
- 6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64
- bit platforms. Using this directory requires an installation of
- Microsoft Visual C++ 2015 (MSVC 14.0) of any edition. The specific
- requirements are as follows:
-
- Visual Studio Express 2015 for Desktop
- Visual Studio Professional 2015
- Either edition is sufficient for building all configurations except
- for Profile Guided Optimization.
- The Python build solution pcbuild.sln makes use of Solution Folders,
- which this edition does not support. Any time pcbuild.sln is opened
- or reloaded by Visual Studio, a warning about Solution Folders will
- be displayed, which can be safely dismissed with no impact on your
- ability to build Python.
- Required for building 64-bit Debug and Release configuration builds
- Visual Studio Premium 2015
- Required for building Release configuration builds that make use of
- Profile Guided Optimization (PGO), on either platform.
-
- All you need to do to build is open the solution "pcbuild.sln" in Visual
- Studio, select the desired combination of configuration and platform,
- then build with "Build Solution". You can also build from the command
- line using the "build.bat" script in this directory; see below for
- details. The solution is configured to build the projects in the correct
- order.
-
- The solution currently supports two platforms. The Win32 platform is
- used to build standard x86-compatible 32-bit binaries, output into the
- win32 sub-directory. The x64 platform is used for building 64-bit AMD64
- (aka x86_64 or EM64T) binaries, output into the amd64 sub-directory.
- The Itanium (IA-64) platform is no longer supported. See the "Building
- for AMD64" section below for more information about 64-bit builds.
-
- Four configuration options are supported by the solution:
- Debug
- Used to build Python with extra debugging capabilities, equivalent
- to using ./configure --with-pydebug on UNIX. All binaries built
- using this configuration have "_d" added to their name:
- python35_d.dll, python_d.exe, parser_d.pyd, and so on. Both the
- build and rt (run test) batch files in this directory accept a -d
- option for debug builds. If you are building Python to help with
- development of CPython, you will most likely use this configuration.
- PGInstrument, PGUpdate
- Used to build Python in Release configuration using PGO, which
- requires Premium Edition of Visual Studio. See the "Profile
- Guided Optimization" section below for more information. Build
- output from each of these configurations lands in its own
- sub-directory of this directory. The official Python releases may
- be built using these configurations.
- Release
- Used to build Python as it is meant to be used in production
- settings, though without PGO.
-
-
- Building Python using the build.bat script
- ----------------------------------------------
-
- In this directory you can find build.bat, a script designed to make
- building Python on Windows simpler. This script will use the env.bat
- script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of
- which may be used to build Python, though only Visual Studio 2015 is
- officially supported.
-
- By default, build.bat will build Python in Release configuration for
- the 32-bit Win32 platform. It accepts several arguments to change
- this behavior:
-
- -c <configuration> Set the configuration (see above)
- -d Shortcut for "-c Debug"
- -p <platform> Set the platform to build for ("Win32" or "x64")
- -r Rebuild instead of just building
- -t <target> Set the target (Build, Rebuild, Clean or CleanAll)
- -e Use get_externals.bat to fetch external sources
- -M Don't build in parallel
- -v Increased output messages
-
- Up to 9 MSBuild switches can also be passed, though they must be passed
- after specifying any of the above switches. For example, use:
-
- build.bat -e -d /fl
-
- to do a debug build with externals fetched as needed and write detailed
- build logs to a file. If the MSBuild switch requires an equal sign
- ("="), the entire switch must be quoted:
-
- build.bat -e -d "/p:ExternalsDir=P:\cpython-externals"
-
- There may also be other situations where quotes are necessary.
-
-
- C Runtime
- ---------
-
- Visual Studio 2015 uses version 14 of the C runtime (MSVCRT14). The
- executables no longer use the "Side by Side" assemblies used in previous
- versions of the compiler. This simplifies distribution of applications.
-
- The run time libraries are available under the VC/Redist folder of your
- Visual Studio distribution. For more info, see the Readme in the
- VC/Redist folder.
-
-
- Sub-Projects
- ------------
-
- The CPython project is split up into several smaller sub-projects which
- are managed by the pcbuild.sln solution file. Each sub-project is
- represented by a .vcxproj and a .vcxproj.filters file starting with the
- name of the sub-project. These sub-projects fall into a few general
- categories:
-
- The following sub-projects represent the bare minimum required to build
- a functioning CPython interpreter. If nothing else builds but these,
- you'll have a very limited but usable python.exe:
- pythoncore
- .dll and .lib
- python
- .exe
- make_buildinfo, make_versioninfo
- helpers to provide necessary information to the build process
-
- These sub-projects provide extra executables that are useful for running
- CPython in different ways:
- pythonw
- pythonw.exe, a variant of python.exe that doesn't open a Command
- Prompt window
- pylauncher
- py.exe, the Python Launcher for Windows, see
- http://docs.python.org/3/using/windows.html#launcher
- pywlauncher
- pyw.exe, a variant of py.exe that doesn't open a Command Prompt
- window
- _testembed
- _testembed.exe, a small program that embeds Python for testing
- purposes, used by test_capi.py
-
- These are miscellaneous sub-projects that don't really fit the other
- categories:
- _freeze_importlib
- _freeze_importlib.exe, used to regenerate Python\importlib.h after
- changes have been made to Lib\importlib\_bootstrap.py
- bdist_wininst
- ..\Lib\distutils\command\wininst-14.0[-amd64].exe, the base
- executable used by the distutils bdist_wininst command
- python3dll
- python3.dll, the PEP 384 Stable ABI dll
- xxlimited
- builds an example module that makes use of the PEP 384 Stable ABI,
- see Modules\xxlimited.c
-
- The following sub-projects are for individual modules of the standard
- library which are implemented in C; each one builds a DLL (renamed to
- .pyd) of the same name as the project:
- _ctypes
- _ctypes_test
- _decimal
- _elementtree
- _hashlib
- _msi
- _multiprocessing
- _overlapped
- _socket
- _testcapi
- _testbuffer
- _testimportmultiple
- pyexpat
- select
- unicodedata
- winsound
-
- The following Python-controlled sub-projects wrap external projects.
- Note that these external libraries are not necessary for a working
- interpreter, but they do implement several major features. See the
- "Getting External Sources" section below for additional information
- about getting the source for building these libraries. The sub-projects
- are:
- _bz2
- Python wrapper for version 1.0.6 of the libbzip2 compression library
- Homepage:
- http://www.bzip.org/
- _lzma
- Python wrapper for the liblzma compression library, using pre-built
- binaries of XZ Utils version 5.0.5
- Homepage:
- http://tukaani.org/xz/
- _ssl
- Python wrapper for version 1.0.1j of the OpenSSL secure sockets
- library, which is built by ssl.vcxproj
- Homepage:
- http://www.openssl.org/
-
- Building OpenSSL requires nasm.exe (the Netwide Assembler), version
- 2.10 or newer from
- http://www.nasm.us/
- to be somewhere on your PATH. More recent versions of OpenSSL may
- need a later version of NASM. If OpenSSL's self tests don't pass,
- you should first try to update NASM and do a full rebuild of
- OpenSSL. get_externals.py also downloads a snapshot of NASM, and the
- libeay and ssleay sub-projects use that version of nasm.exe.
-
- The libeay/ssleay sub-projects expect your OpenSSL sources to have
- already been configured and be ready to build. If you get your sources
- from svn.python.org as suggested in the "Getting External Sources"
- section below, the OpenSSL source will already be ready to go. If
- you want to build a different version, you will need to run
-
- PCbuild\prepare_ssl.py path\to\openssl-source-dir
-
- That script will prepare your OpenSSL sources in the same way that
- those available on svn.python.org have been prepared. Note that
- Perl must be installed and available on your PATH to configure
- OpenSSL. ActivePerl is recommended and is available from
- http://www.activestate.com/activeperl/
-
- The libeay and ssleay sub-projects will build the modules of OpenSSL
- required by _ssl and _hashlib and may need to be manually updated when
- upgrading to a newer version of OpenSSL or when adding new
- functionality to _ssl or _hashlib. They will not clean up their output
- with the normal Clean target; CleanAll should be used instead.
- _sqlite3
- Wraps SQLite 3.8.3.1, which is itself built by sqlite3.vcxproj
- Homepage:
- http://www.sqlite.org/
- _tkinter
- Wraps version 8.6.1 of the Tk windowing system.
- Homepage:
- http://www.tcl.tk/
-
- Tkinter's dependencies are built by the tcl.vcxproj and tk.vcxproj
- projects. The tix.vcxproj project also builds the Tix extended
- widget set for use with Tkinter.
-
- Those three projects install their respective components in a
- directory alongside the source directories called "tcltk" on
- Win32 and "tcltk64" on x64. They also copy the Tcl and Tk DLLs
- into the current output directory, which should ensure that Tkinter
- is able to load Tcl/Tk without having to change your PATH.
-
- The tcl, tk, and tix sub-projects do not clean their builds with
- the normal Clean target; if you need to rebuild, you should use the
- CleanAll target or manually delete their builds.
-
-
- Getting External Sources
- ------------------------
-
- The last category of sub-projects listed 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. However, a simple script is provided to make this as
- painless as possible, called "get_externals.bat" and located in this
- directory. This script extracts all the external sub-projects from
- http://svn.python.org/projects/external
- via Subversion (so you'll need svn.exe on your PATH) and places them
- in ..\externals (relative to this directory).
-
- It is also possible to download sources from each project's homepage,
- though you may have to change folder names or pass the names to MSBuild
- as the values of certain properties in order for the build solution to
- find them. This is an advanced topic and not necessarily fully
- supported.
-
-
- Building for AMD64
- ------------------
-
- The build process for AMD64 / x64 is very similar to standard builds,
- you just have to set x64 as platform. In addition, the HOST_PYTHON
- environment variable must point to a Python interpreter (at least 2.4),
- to support cross-compilation from Win32.
-
-
- Profile Guided Optimization
- ---------------------------
-
- The solution has two configurations for PGO. The PGInstrument
- configuration must be built first. The PGInstrument binaries are linked
- against a profiling library and contain extra debug information. The
- PGUpdate configuration takes the profiling data and generates optimized
- binaries.
-
- The build_pgo.bat script automates the creation of optimized binaries.
- It creates the PGI files, runs the unit test suite or PyBench with the
- PGI python, and finally creates the optimized files.
-
- See
- http://msdn.microsoft.com/en-us/library/e7k32f4k(VS.100).aspx
- for more on this topic.
-
-
- Static library
- --------------
-
- The solution has no configuration for static libraries. However it is
- easy to build a static library instead of a DLL. You simply have to set
- the "Configuration Type" to "Static Library (.lib)" and alter the
- preprocessor macro "Py_ENABLE_SHARED" to "Py_NO_ENABLE_SHARED". You may
- also have to change the "Runtime Library" from "Multi-threaded DLL
- (/MD)" to "Multi-threaded (/MT)".
-
-
- Visual Studio properties
- ------------------------
-
- The PCbuild solution makes use of Visual Studio property files (*.props)
- to simplify each project. The properties can be viewed in the Property
- Manager (View -> Other Windows -> Property Manager) but should be
- carefully modified by hand.
-
- The property files used are:
- * python (versions, directories and build names)
- * pyproject (base settings for all projects)
- * openssl (used by libeay and ssleay projects)
- * tcltk (used by _tkinter, tcl, tk and tix projects)
-
- The pyproject property file defines all of the build settings for each
- project, with some projects overriding certain specific values. The GUI
- doesn't always reflect the correct settings and may confuse the user
- with false information, especially for settings that automatically adapt
- for diffirent configurations.
-
-
- Your Own Extension DLLs
- -----------------------
-
- If you want to create your own extension module DLL (.pyd), there's an
- example with easy-to-follow instructions in ..\PC\example\; read the
- file readme.txt there first.
++Quick Start Guide\r
++-----------------\r
++\r
++1. Install Microsoft Visual Studio 2015, any edition.\r
++2. Install Subversion, and make sure 'svn.exe' is on your PATH.\r
++3. Run "build.bat -e" to build Python in 32-bit Release configuration.\r
++4. (Optional, but recommended) Run the test suite with "rt.bat -q".\r
++\r
++\r
+ Building Python using Microsoft Visual C++\r
+ ------------------------------------------\r
+ \r
+ This directory is used to build CPython for Microsoft Windows NT version\r
-5.1 or higher (Windows XP, Windows Server 2003, or later) on 32 and 64\r
++6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64\r
+ bit platforms. Using this directory requires an installation of\r
-Microsoft Visual C++ 2010 (MSVC 10.0) of any edition. The specific\r
++Microsoft Visual C++ 2015 (MSVC 14.0) of any edition. The specific\r
+ requirements are as follows:\r
+ \r
-Visual C++ 2010 Express Edition\r
- Required for building 32-bit Debug and Release configuration builds.\r
++Visual Studio Express 2015 for Desktop\r
++Visual Studio Professional 2015\r
++ Either edition is sufficient for building all configurations except\r
++ for Profile Guided Optimization.\r
+ The Python build solution pcbuild.sln makes use of Solution Folders,\r
+ which this edition does not support. Any time pcbuild.sln is opened\r
- or reloaded by Visual C++, a warning about Solution Folders will be\r
- displayed which can be safely dismissed with no impact on your\r
++ or reloaded by Visual Studio, a warning about Solution Folders will\r
++ be displayed, which can be safely dismissed with no impact on your\r
+ ability to build Python.\r
-Visual Studio 2010 Professional Edition\r
+ Required for building 64-bit Debug and Release configuration builds\r
-Visual Studio 2010 Premium Edition\r
++Visual Studio Premium 2015\r
+ Required for building Release configuration builds that make use of\r
+ Profile Guided Optimization (PGO), on either platform.\r
+ \r
-Installing Service Pack 1 for Visual Studio 2010 is highly recommended\r
-to avoid LNK1123 errors.\r
-\r
+ All you need to do to build is open the solution "pcbuild.sln" in Visual\r
+ Studio, select the desired combination of configuration and platform,\r
-then build with "Build Solution" or the F7 keyboard shortcut. You can\r
-also build from the command line using the "build.bat" script in this\r
-directory. The solution is configured to build the projects in the\r
-correct order.\r
++then build with "Build Solution". You can also build from the command\r
++line using the "build.bat" script in this directory; see below for\r
++details. The solution is configured to build the projects in the correct\r
++order.\r
+ \r
+ The solution currently supports two platforms. The Win32 platform is\r
-used to build standard x86-compatible 32-bit binaries, output into this\r
-directory. The x64 platform is used for building 64-bit AMD64 (aka\r
-x86_64 or EM64T) binaries, output into the amd64 sub-directory which\r
-will be created if it doesn't already exist. The Itanium (IA-64)\r
-platform is no longer supported. See the "Building for AMD64" section\r
-below for more information about 64-bit builds.\r
++used to build standard x86-compatible 32-bit binaries, output into the\r
++win32 sub-directory. The x64 platform is used for building 64-bit AMD64\r
++(aka x86_64 or EM64T) binaries, output into the amd64 sub-directory.\r
++The Itanium (IA-64) platform is no longer supported. See the "Building\r
++for AMD64" section below for more information about 64-bit builds.\r
+ \r
+ Four configuration options are supported by the solution:\r
+ Debug\r
+ Used to build Python with extra debugging capabilities, equivalent\r
+ to using ./configure --with-pydebug on UNIX. All binaries built\r
+ using this configuration have "_d" added to their name:\r
- python34_d.dll, python_d.exe, parser_d.pyd, and so on. Both the\r
++ python35_d.dll, python_d.exe, parser_d.pyd, and so on. Both the\r
+ build and rt (run test) batch files in this directory accept a -d\r
+ option for debug builds. If you are building Python to help with\r
+ development of CPython, you will most likely use this configuration.\r
+ PGInstrument, PGUpdate\r
+ Used to build Python in Release configuration using PGO, which\r
+ requires Premium Edition of Visual Studio. See the "Profile\r
+ Guided Optimization" section below for more information. Build\r
+ output from each of these configurations lands in its own\r
- sub-directory of this directory. The official Python releases are\r
- built using these configurations.\r
++ sub-directory of this directory. The official Python releases may\r
++ be built using these configurations.\r
+ Release\r
+ Used to build Python as it is meant to be used in production\r
+ settings, though without PGO.\r
+ \r
+ \r
-Legacy support\r
---------------\r
++Building Python using the build.bat script\r
++----------------------------------------------\r
++\r
++In this directory you can find build.bat, a script designed to make\r
++building Python on Windows simpler. This script will use the env.bat\r
++script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of\r
++which may be used to build Python, though only Visual Studio 2015 is\r
++officially supported.\r
++\r
++By default, build.bat will build Python in Release configuration for\r
++the 32-bit Win32 platform. It accepts several arguments to change\r
++this behavior:\r
+ \r
-You can find build directories for older versions of Visual Studio and\r
-Visual C++ in the PC directory. The legacy build directories are no\r
-longer actively maintained and may not work out of the box.\r
++ -c <configuration> Set the configuration (see above)\r
++ -d Shortcut for "-c Debug"\r
++ -p <platform> Set the platform to build for ("Win32" or "x64")\r
++ -r Rebuild instead of just building\r
++ -t <target> Set the target (Build, Rebuild, Clean or CleanAll)\r
++ -e Use get_externals.bat to fetch external sources\r
++ -M Don't build in parallel\r
++ -v Increased output messages\r
+ \r
-Currently, the only legacy build directory is PC\VS9.0, for Visual\r
-Studio 2008 (9.0).\r
++Up to 9 MSBuild switches can also be passed, though they must be passed\r
++after specifying any of the above switches. For example, use:\r
++\r
++ build.bat -e -d /fl\r
++\r
++to do a debug build with externals fetched as needed and write detailed\r
++build logs to a file. If the MSBuild switch requires an equal sign\r
++("="), the entire switch must be quoted:\r
++\r
++ build.bat -e -d "/p:ExternalsDir=P:\cpython-externals"\r
++\r
++There may also be other situations where quotes are necessary.\r
+ \r
+ \r
+ C Runtime\r
+ ---------\r
+ \r
-Visual Studio 2010 uses version 10 of the C runtime (MSVCRT10). The\r
++Visual Studio 2015 uses version 14 of the C runtime (MSVCRT14). The\r
+ executables no longer use the "Side by Side" assemblies used in previous\r
+ versions of the compiler. This simplifies distribution of applications.\r
+ \r
+ The run time libraries are available under the VC/Redist folder of your\r
+ Visual Studio distribution. For more info, see the Readme in the\r
+ VC/Redist folder.\r
+ \r
+ \r
+ Sub-Projects\r
+ ------------\r
+ \r
+ The CPython project is split up into several smaller sub-projects which\r
+ are managed by the pcbuild.sln solution file. Each sub-project is\r
+ represented by a .vcxproj and a .vcxproj.filters file starting with the\r
+ name of the sub-project. These sub-projects fall into a few general\r
+ categories:\r
+ \r
+ The following sub-projects represent the bare minimum required to build\r
+ a functioning CPython interpreter. If nothing else builds but these,\r
+ you'll have a very limited but usable python.exe:\r
+ pythoncore\r
+ .dll and .lib\r
+ python\r
+ .exe\r
-kill_python\r
- kill_python.exe, a small program designed to kill any instances of\r
- python(_d).exe that are running and live in the build output\r
- directory; this is meant to avoid build issues due to locked files\r
+ make_buildinfo, make_versioninfo\r
+ helpers to provide necessary information to the build process\r
+ \r
+ These sub-projects provide extra executables that are useful for running\r
+ CPython in different ways:\r
+ pythonw\r
+ pythonw.exe, a variant of python.exe that doesn't open a Command\r
+ Prompt window\r
+ pylauncher\r
+ py.exe, the Python Launcher for Windows, see\r
+ http://docs.python.org/3/using/windows.html#launcher\r
+ pywlauncher\r
+ pyw.exe, a variant of py.exe that doesn't open a Command Prompt\r
+ window\r
+ _testembed\r
+ _testembed.exe, a small program that embeds Python for testing\r
+ purposes, used by test_capi.py\r
+ \r
+ These are miscellaneous sub-projects that don't really fit the other\r
-categories. By default, these projects do not build in Debug\r
-configuration:\r
++categories:\r
+ _freeze_importlib\r
+ _freeze_importlib.exe, used to regenerate Python\importlib.h after\r
+ changes have been made to Lib\importlib\_bootstrap.py\r
+ bdist_wininst\r
- ..\Lib\distutils\command\wininst-10.0[-amd64].exe, the base\r
++ ..\Lib\distutils\command\wininst-14.0[-amd64].exe, the base\r
+ executable used by the distutils bdist_wininst command\r
+ python3dll\r
+ python3.dll, the PEP 384 Stable ABI dll\r
+ xxlimited\r
+ builds an example module that makes use of the PEP 384 Stable ABI,\r
+ see Modules\xxlimited.c\r
+ \r
+ The following sub-projects are for individual modules of the standard\r
+ library which are implemented in C; each one builds a DLL (renamed to\r
+ .pyd) of the same name as the project:\r
+ _ctypes\r
+ _ctypes_test\r
+ _decimal\r
+ _elementtree\r
+ _hashlib\r
+ _msi\r
+ _multiprocessing\r
+ _overlapped\r
+ _socket\r
+ _testcapi\r
+ _testbuffer\r
+ _testimportmultiple\r
+ pyexpat\r
+ select\r
+ unicodedata\r
+ winsound\r
+ \r
+ The following Python-controlled sub-projects wrap external projects.\r
+ Note that these external libraries are not necessary for a working\r
+ interpreter, but they do implement several major features. See the\r
+ "Getting External Sources" section below for additional information\r
+ about getting the source for building these libraries. The sub-projects\r
+ are:\r
+ _bz2\r
+ Python wrapper for version 1.0.6 of the libbzip2 compression library\r
+ Homepage:\r
+ http://www.bzip.org/\r
+ _lzma\r
+ Python wrapper for the liblzma compression library, using pre-built\r
+ binaries of XZ Utils version 5.0.5\r
+ Homepage:\r
+ http://tukaani.org/xz/\r
+ _ssl\r
- Python wrapper for version 1.0.2a of the OpenSSL secure sockets\r
++ Python wrapper for version 1.0.1j of the OpenSSL secure sockets\r
+ library, which is built by ssl.vcxproj\r
+ Homepage:\r
+ http://www.openssl.org/\r
+ \r
+ Building OpenSSL requires nasm.exe (the Netwide Assembler), version\r
+ 2.10 or newer from\r
+ http://www.nasm.us/\r
+ to be somewhere on your PATH. More recent versions of OpenSSL may\r
+ need a later version of NASM. If OpenSSL's self tests don't pass,\r
+ you should first try to update NASM and do a full rebuild of\r
- OpenSSL. If you use the Tools\buildbot\external(-amd64).bat method\r
- for getting sources, it also downloads a version of NASM which the\r
- ssl build script will add to PATH.\r
-\r
- If you like to use the official sources instead of the files from\r
- python.org's subversion repository, Perl is required to build the\r
- necessary makefiles and assembly files. ActivePerl is available\r
- from\r
++ OpenSSL. get_externals.py also downloads a snapshot of NASM, and the\r
++ libeay and ssleay sub-projects use that version of nasm.exe.\r
++\r
++ The libeay/ssleay sub-projects expect your OpenSSL sources to have\r
++ already been configured and be ready to build. If you get your sources\r
++ from svn.python.org as suggested in the "Getting External Sources"\r
++ section below, the OpenSSL source will already be ready to go. If\r
++ you want to build a different version, you will need to run\r
++\r
++ PCbuild\prepare_ssl.py path\to\openssl-source-dir\r
++\r
++ That script will prepare your OpenSSL sources in the same way that\r
++ those available on svn.python.org have been prepared. Note that\r
++ Perl must be installed and available on your PATH to configure\r
++ OpenSSL. ActivePerl is recommended and is available from\r
+ http://www.activestate.com/activeperl/\r
- The svn.python.org version contains pre-built makefiles and assembly\r
- files.\r
-\r
- The build process makes sure that no patented algorithms are\r
- included. For now RC5, MDC2 and IDEA are excluded from the build.\r
- You may have to manually remove $(OBJ_D)\i_*.obj from ms\nt.mak if\r
- using official sources; the svn.python.org-hosted version is already\r
- fixed.\r
-\r
- The ssl.vcxproj sub-project simply invokes PCbuild/build_ssl.py,\r
- which locates and builds OpenSSL.\r
-\r
- build_ssl.py attempts to catch the most common errors (such as not\r
- being able to find OpenSSL sources, or not being able to find a Perl\r
- that works with OpenSSL) and give a reasonable error message. If\r
- you have a problem that doesn't seem to be handled correctly (e.g.,\r
- you know you have ActivePerl but we can't find it), please take a\r
- peek at build_ssl.py and suggest patches. Note that build_ssl.py\r
- should be able to be run directly from the command-line.\r
-\r
- The ssl sub-project does not have the ability to clean the OpenSSL\r
- build; if you need to rebuild, you'll have to clean it by hand.\r
++\r
++ The libeay and ssleay sub-projects will build the modules of OpenSSL\r
++ required by _ssl and _hashlib and may need to be manually updated when\r
++ upgrading to a newer version of OpenSSL or when adding new\r
++ functionality to _ssl or _hashlib. They will not clean up their output\r
++ with the normal Clean target; CleanAll should be used instead.\r
+ _sqlite3\r
+ Wraps SQLite 3.8.3.1, which is itself built by sqlite3.vcxproj\r
+ Homepage:\r
+ http://www.sqlite.org/\r
+ _tkinter\r
+ Wraps version 8.6.1 of the Tk windowing system.\r
+ Homepage:\r
+ http://www.tcl.tk/\r
+ \r
- Unlike the other external libraries listed above, Tk must be built\r
- separately before the _tkinter module can be built. This means that\r
- a pre-built Tcl/Tk installation is expected in ..\externals\tcltk\r
- (tcltk64 for 64-bit) relative to this directory. See "Getting\r
- External Sources" below for the easiest method to ensure Tcl/Tk is\r
- built.\r
++ Tkinter's dependencies are built by the tcl.vcxproj and tk.vcxproj\r
++ projects. The tix.vcxproj project also builds the Tix extended\r
++ widget set for use with Tkinter.\r
++\r
++ Those three projects install their respective components in a\r
++ directory alongside the source directories called "tcltk" on\r
++ Win32 and "tcltk64" on x64. They also copy the Tcl and Tk DLLs\r
++ into the current output directory, which should ensure that Tkinter\r
++ is able to load Tcl/Tk without having to change your PATH.\r
++\r
++ The tcl, tk, and tix sub-projects do not clean their builds with\r
++ the normal Clean target; if you need to rebuild, you should use the\r
++ CleanAll target or manually delete their builds.\r
+ \r
+ \r
+ Getting External Sources\r
+ ------------------------\r
+ \r
+ The last category of sub-projects listed above wrap external projects\r
+ Python doesn't control, and as such a little more work is required in\r
+ order to download the relevant source files for each project before they\r
-can be built. The buildbots must ensure that all libraries are present\r
-before building, so the easiest approach is to run either external.bat\r
-or external-amd64.bat (depending on platform) in the ..\Tools\buildbot\r
-directory from ..\, i.e.:\r
-\r
- C:\python\cpython\PCbuild>cd ..\r
- C:\python\cpython>Tools\buildbot\external.bat\r
-\r
-This extracts all the external sub-projects from\r
++can be built. However, a simple script is provided to make this as\r
++painless as possible, called "get_externals.bat" and located in this\r
++directory. This script extracts all the external sub-projects from\r
+ http://svn.python.org/projects/external\r
-via Subversion (so you'll need an svn.exe on your PATH) and places them\r
++via Subversion (so you'll need svn.exe on your PATH) and places them\r
+ in ..\externals (relative to this directory).\r
+ \r
+ It is also possible to download sources from each project's homepage,\r
-though you may have to change the names of some folders in order to make\r
-things work. For instance, if you were to download a version 5.0.7 of\r
-XZ Utils, you would need to extract the archive into ..\externals\xz-5.0.5\r
-anyway, since that is where the solution is set to look for xz. The\r
-same is true for all other external projects.\r
-\r
-The external(-amd64).bat scripts will also build a debug build of\r
-Tcl/Tk, but there aren't any equivalent batch files for building release\r
-versions of Tcl/Tk currently available. If you need to build a release\r
-version of Tcl/Tk, just take a look at the relevant external(-amd64).bat\r
-file and find the two nmake lines, then call each one without the\r
-'DEBUG=1' parameter, i.e.:\r
-\r
-The external-amd64.bat file contains this for tcl:\r
- nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install\r
-\r
-So for a release build, you'd call it as:\r
- nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install\r
-\r
-Note that the above command is called from within ..\externals\tcl-8.6.1.0\win\r
-(relative to this directory); don't forget to build Tk as well as Tcl!\r
-\r
-This will be cleaned up in the future; http://bugs.python.org/issue15968\r
-tracks adding a new tcltk.vcxproj file that will build Tcl/Tk and Tix\r
-the same way the other external projects listed above are built.\r
++though you may have to change folder names or pass the names to MSBuild\r
++as the values of certain properties in order for the build solution to\r
++find them. This is an advanced topic and not necessarily fully\r
++supported.\r
+ \r
+ \r
+ Building for AMD64\r
+ ------------------\r
+ \r
+ The build process for AMD64 / x64 is very similar to standard builds,\r
+ you just have to set x64 as platform. In addition, the HOST_PYTHON\r
+ environment variable must point to a Python interpreter (at least 2.4),\r
-to support cross-compilation from Win32. Note that Visual Studio\r
-requires Professional Edition or better in order to build 64-bit\r
-binaries.\r
++to support cross-compilation from Win32.\r
+ \r
+ \r
+ Profile Guided Optimization\r
+ ---------------------------\r
+ \r
+ The solution has two configurations for PGO. The PGInstrument\r
+ configuration must be built first. The PGInstrument binaries are linked\r
+ against a profiling library and contain extra debug information. The\r
+ PGUpdate configuration takes the profiling data and generates optimized\r
+ binaries.\r
+ \r
+ The build_pgo.bat script automates the creation of optimized binaries.\r
+ It creates the PGI files, runs the unit test suite or PyBench with the\r
+ PGI python, and finally creates the optimized files.\r
+ \r
+ See\r
+ http://msdn.microsoft.com/en-us/library/e7k32f4k(VS.100).aspx\r
+ for more on this topic.\r
+ \r
+ \r
+ Static library\r
+ --------------\r
+ \r
+ The solution has no configuration for static libraries. However it is\r
+ easy to build a static library instead of a DLL. You simply have to set\r
+ the "Configuration Type" to "Static Library (.lib)" and alter the\r
+ preprocessor macro "Py_ENABLE_SHARED" to "Py_NO_ENABLE_SHARED". You may\r
+ also have to change the "Runtime Library" from "Multi-threaded DLL\r
+ (/MD)" to "Multi-threaded (/MT)".\r
+ \r
+ \r
+ Visual Studio properties\r
+ ------------------------\r
+ \r
-The PCbuild solution makes heavy use of Visual Studio property files\r
-(*.props). The properties can be viewed and altered in the Property\r
-Manager (View -> Other Windows -> Property Manager).\r
-\r
-The property files used are (+-- = "also imports"):\r
- * debug (debug macro: _DEBUG)\r
- * pginstrument (PGO)\r
- * pgupdate (PGO)\r
- +-- pginstrument\r
- * pyd (python extension, release build)\r
- +-- release\r
- +-- pyproject\r
- * pyd_d (python extension, debug build)\r
- +-- debug\r
- +-- pyproject\r
- * pyproject (base settings for all projects, user macros like PyDllName)\r
- * release (release macro: NDEBUG)\r
- * sqlite3 (used only by sqlite3.vcxproj)\r
- * x64 (AMD64 / x64 platform specific settings)\r
-\r
-The pyproject property file defines _WIN32 and x64 defines _WIN64 and\r
-_M_X64 although the macros are set by the compiler, too. The GUI doesn't\r
-always know about the macros and confuse the user with false\r
-information.\r
++The PCbuild solution makes use of Visual Studio property files (*.props)\r
++to simplify each project. The properties can be viewed in the Property\r
++Manager (View -> Other Windows -> Property Manager) but should be\r
++carefully modified by hand.\r
++\r
++The property files used are:\r
++ * python (versions, directories and build names)\r
++ * pyproject (base settings for all projects)\r
++ * openssl (used by libeay and ssleay projects)\r
++ * tcltk (used by _tkinter, tcl, tk and tix projects)\r
++\r
++The pyproject property file defines all of the build settings for each\r
++project, with some projects overriding certain specific values. The GUI\r
++doesn't always reflect the correct settings and may confuse the user\r
++with false information, especially for settings that automatically adapt\r
++for diffirent configurations.\r
+ \r
+ \r
+ Your Own Extension DLLs\r
+ -----------------------\r
+ \r
+ If you want to create your own extension module DLL (.pyd), there's an\r
+ example with easy-to-follow instructions in ..\PC\example\; read the\r
+ file readme.txt there first.\r
projects / python / commitdiff