-Building Python using Microsoft Visual C++
-------------------------------------------
-
-This directory is used to build CPython for Microsoft Windows NT version
-5.1 or higher (Windows XP, Windows Server 2003, or later) on 32 and 64
-bit platforms. Using this directory requires an installation of
-Microsoft Visual C++ 2010 (MSVC 10.0) of any edition. The specific
-requirements are as follows:
-
-Visual C++ 2010 Express Edition
- Required for building 32-bit Debug and Release configuration builds.
- 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 C++, a warning about Solution Folders will be
- displayed which can be safely dismissed with no impact on your
- ability to build Python.
-Visual Studio 2010 Professional Edition
- Required for building 64-bit Debug and Release configuration builds
-Visual Studio 2010 Premium Edition
- Required for building Release configuration builds that make use of
- Profile Guided Optimization (PGO), on either platform.
-
-Installing Service Pack 1 for Visual Studio 2010 is highly recommended
-to avoid LNK1123 errors.
-
-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" or the F7 keyboard shortcut. You can
-also build from the command line using the "build.bat" script in this
-directory. 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 this
-directory. The x64 platform is used for building 64-bit AMD64 (aka
-x86_64 or EM64T) binaries, output into the amd64 sub-directory which
-will be created if it doesn't already exist. 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:
- python34_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 are
- built using these configurations.
-Release
- Used to build Python as it is meant to be used in production
- settings, though without PGO.
-
-
-Legacy support
---------------
-
-You can find build directories for older versions of Visual Studio and
-Visual C++ in the PC directory. The legacy build directories are no
-longer actively maintained and may not work out of the box.
-
-Currently, the only legacy build directory is PC\VS9.0, for Visual
-Studio 2008 (9.0).
-
-
-C Runtime
----------
-
-Visual Studio 2010 uses version 10 of the C runtime (MSVCRT10). 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
-kill_python
- kill_python.exe, a small program designed to kill any instances of
- python(_d).exe that are running and live in the build output
- directory; this is meant to avoid build issues due to locked files
-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. By default, these projects do not build in Debug
-configuration:
-_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-10.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.2a 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. If you use the Tools\buildbot\external(-amd64).bat method
- for getting sources, it also downloads a version of NASM which the
- ssl build script will add to PATH.
-
- If you like to use the official sources instead of the files from
- python.org's subversion repository, Perl is required to build the
- necessary makefiles and assembly files. ActivePerl is available
- from
- http://www.activestate.com/activeperl/
- The svn.python.org version contains pre-built makefiles and assembly
- files.
-
- The build process makes sure that no patented algorithms are
- included. For now RC5, MDC2 and IDEA are excluded from the build.
- You may have to manually remove $(OBJ_D)\i_*.obj from ms\nt.mak if
- using official sources; the svn.python.org-hosted version is already
- fixed.
-
- The ssl.vcxproj sub-project simply invokes PCbuild/build_ssl.py,
- which locates and builds OpenSSL.
-
- build_ssl.py attempts to catch the most common errors (such as not
- being able to find OpenSSL sources, or not being able to find a Perl
- that works with OpenSSL) and give a reasonable error message. If
- you have a problem that doesn't seem to be handled correctly (e.g.,
- you know you have ActivePerl but we can't find it), please take a
- peek at build_ssl.py and suggest patches. Note that build_ssl.py
- should be able to be run directly from the command-line.
-
- The ssl sub-project does not have the ability to clean the OpenSSL
- build; if you need to rebuild, you'll have to clean it by hand.
-_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/
-
- Unlike the other external libraries listed above, Tk must be built
- separately before the _tkinter module can be built. This means that
- a pre-built Tcl/Tk installation is expected in ..\externals\tcltk
- (tcltk64 for 64-bit) relative to this directory. See "Getting
- External Sources" below for the easiest method to ensure Tcl/Tk is
- built.
-
-
-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. The buildbots must ensure that all libraries are present
-before building, so the easiest approach is to run either external.bat
-or external-amd64.bat (depending on platform) in the ..\Tools\buildbot
-directory from ..\, i.e.:
-
- C:\python\cpython\PCbuild>cd ..
- C:\python\cpython>Tools\buildbot\external.bat
-
-This extracts all the external sub-projects from
- http://svn.python.org/projects/external
-via Subversion (so you'll need an 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 the names of some folders in order to make
-things work. For instance, if you were to download a version 5.0.7 of
-XZ Utils, you would need to extract the archive into ..\externals\xz-5.0.5
-anyway, since that is where the solution is set to look for xz. The
-same is true for all other external projects.
-
-The external(-amd64).bat scripts will also build a debug build of
-Tcl/Tk, but there aren't any equivalent batch files for building release
-versions of Tcl/Tk currently available. If you need to build a release
-version of Tcl/Tk, just 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 DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
-
-So for a release build, you'd call it as:
- nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
-
-Note that the above command is called from within ..\externals\tcl-8.6.1.0\win
-(relative to this directory); don't forget to build Tk as well as Tcl!
-
-This will be cleaned up in the future; http://bugs.python.org/issue15968
-tracks adding a new tcltk.vcxproj file that will build Tcl/Tk and Tix
-the same way the other external projects listed above are built.
-
-
-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. Note that Visual Studio
-requires Professional Edition or better in order to build 64-bit
-binaries.
-
-
-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 heavy use of Visual Studio property files
-(*.props). The properties can be viewed and altered in the Property
-Manager (View -> Other Windows -> Property Manager).
-
-The property files used are (+-- = "also imports"):
- * debug (debug macro: _DEBUG)
- * pginstrument (PGO)
- * pgupdate (PGO)
- +-- pginstrument
- * pyd (python extension, release build)
- +-- release
- +-- pyproject
- * pyd_d (python extension, debug build)
- +-- debug
- +-- pyproject
- * pyproject (base settings for all projects, user macros like PyDllName)
- * release (release macro: NDEBUG)
- * sqlite3 (used only by sqlite3.vcxproj)
- * x64 (AMD64 / x64 platform specific settings)
-
-The pyproject property file defines _WIN32 and x64 defines _WIN64 and
-_M_X64 although the macros are set by the compiler, too. The GUI doesn't
-always know about the macros and confuse the user with false
-information.
-
-
-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.
+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
+bit platforms. Using this directory requires an installation of\r
+Microsoft Visual C++ 2010 (MSVC 10.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
+ 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
+ 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
+ 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
+\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
+\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
+ 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
+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
+\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
+\r
+Currently, the only legacy build directory is PC\VS9.0, for Visual\r
+Studio 2008 (9.0).\r
+\r
+\r
+C Runtime\r
+---------\r
+\r
+Visual Studio 2010 uses version 10 of the C runtime (MSVCRT10). 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
+_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
+ 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
+ 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
+ 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
+_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
+\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
+ http://svn.python.org/projects/external\r
+via Subversion (so you'll need an 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
+\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
+\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
+\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