From 30cc6fae980365da4e3a0e3012629aaf003b2597 Mon Sep 17 00:00:00 2001 From: Zachary Ware Date: Mon, 13 Apr 2015 12:28:11 -0500 Subject: Force the Windows readme to CRLF --- .hgeol | 3 + PCbuild/readme.txt | 708 ++++++++++++++++++++++++++--------------------------- 2 files changed, 357 insertions(+), 354 deletions(-) diff --git a/.hgeol b/.hgeol index 2437601..0555785 100644 --- a/.hgeol +++ b/.hgeol @@ -43,6 +43,9 @@ Lib/test/coding20731.py = BIN # Windows batch files work best with CRLF, there can be subtle problems with LF **.bat = CRLF +# The Windows readme is likely to be read in Notepad, so make it readable +PCbuild/readme.txt = CRLF + # All other files (which presumably are human-editable) are "native". # This must be the last rule! diff --git a/PCbuild/readme.txt b/PCbuild/readme.txt index d5b0dfe..65b75c3 100644 --- a/PCbuild/readme.txt +++ b/PCbuild/readme.txt @@ -1,354 +1,354 @@ -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++ +------------------------------------------ + +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. -- cgit v0.12