2017-06-10 16:58:42 -03:00
|
|
|
Quick Start Guide
|
|
|
|
-----------------
|
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
1. Install Microsoft Visual Studio 2017 with Python workload and
|
|
|
|
Python native development component.
|
2017-06-16 00:08:51 -03:00
|
|
|
1a. Optionally install Python 3.6 or later. If not installed,
|
2017-09-08 00:10:29 -03:00
|
|
|
get_externals.bat (via build.bat) will download and use Python via
|
2017-06-16 00:08:51 -03:00
|
|
|
NuGet.
|
2017-09-08 00:10:29 -03:00
|
|
|
2. Run "build.bat" to build Python in 32-bit Release configuration.
|
2017-06-16 00:08:51 -03:00
|
|
|
3. (Optional, but recommended) Run the test suite with "rt.bat -q".
|
2017-06-10 16:58:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
Building Python using Microsoft Visual C++
|
|
|
|
------------------------------------------
|
|
|
|
|
2022-05-10 03:30:32 -03:00
|
|
|
This directory is used to build CPython for Microsoft Windows on 32- and 64-
|
2017-06-10 16:58:42 -03:00
|
|
|
bit platforms. Using this directory requires an installation of
|
2022-05-10 03:30:32 -03:00
|
|
|
Microsoft Visual Studio (MSVC) with the *Python workload* and
|
|
|
|
its optional *Python native development* component selected.
|
2017-09-08 00:10:29 -03:00
|
|
|
|
|
|
|
Building from the command line is recommended in order to obtain any
|
|
|
|
external dependencies. To build, simply run the "build.bat" script without
|
|
|
|
any arguments. After this succeeds, you can open the "pcbuild.sln"
|
|
|
|
solution in Visual Studio to continue development.
|
2017-06-10 16:58:42 -03:00
|
|
|
|
2017-11-16 19:56:27 -04:00
|
|
|
To build an installer package, refer to the README in the Tools/msi folder.
|
|
|
|
|
2017-06-10 16:58:42 -03:00
|
|
|
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.
|
|
|
|
|
|
|
|
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:
|
2020-05-18 23:33:01 -03:00
|
|
|
python310_d.dll, python_d.exe, parser_d.pyd, and so on. Both the
|
2017-06-10 16:58:42 -03:00
|
|
|
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
|
2017-09-08 00:10:29 -03:00
|
|
|
script to detect either Visual Studio 2017 or 2015, either of
|
|
|
|
which may be used to build Python. Currently Visual Studio 2017 is
|
2017-06-10 16:58:42 -03:00
|
|
|
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, try `build.bat -h` to learn more.
|
|
|
|
|
|
|
|
|
|
|
|
C Runtime
|
|
|
|
---------
|
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
Visual Studio 2017 uses version 14.0 of the C runtime (vcruntime140).
|
|
|
|
The executables no longer use the "Side by Side" assemblies used in
|
|
|
|
previous versions of the compiler. This simplifies distribution of
|
|
|
|
applications.
|
2017-06-10 16:58:42 -03:00
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
The run time libraries are available under the redist folder of your
|
2017-06-10 16:58:42 -03:00
|
|
|
Visual Studio distribution. For more info, see the Readme in the
|
2017-09-08 00:10:29 -03:00
|
|
|
redist folder.
|
2017-06-10 16:58:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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
|
2022-05-10 03:30:32 -03:00
|
|
|
https://docs.python.org/3/using/windows.html#launcher
|
2017-06-10 16:58:42 -03:00
|
|
|
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:
|
2021-08-30 20:25:11 -03:00
|
|
|
_freeze_module
|
|
|
|
_freeze_module.exe, used to regenerate frozen modules in Python
|
|
|
|
after changes have been made to the corresponding source files
|
|
|
|
(e.g. Lib\importlib\_bootstrap.py).
|
2017-09-08 00:10:29 -03:00
|
|
|
pyshellext
|
|
|
|
pyshellext.dll, the shell extension deployed with the launcher
|
2017-06-10 16:58:42 -03:00
|
|
|
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
|
2020-12-08 12:36:53 -04:00
|
|
|
xxlimited_35
|
|
|
|
ditto for testing the Python 3.5 stable ABI, see
|
|
|
|
Modules\xxlimited_35.c
|
2017-06-10 16:58:42 -03:00
|
|
|
|
|
|
|
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:
|
2017-09-08 00:10:29 -03:00
|
|
|
_asyncio
|
2017-06-10 16:58:42 -03:00
|
|
|
_ctypes
|
|
|
|
_ctypes_test
|
bpo-40503: PEP 615: Tests and implementation for zoneinfo (GH-19909)
This is the initial implementation of PEP 615, the zoneinfo module,
ported from the standalone reference implementation (see
https://www.python.org/dev/peps/pep-0615/#reference-implementation for a
link, which has a more detailed commit history).
This includes (hopefully) all functional elements described in the PEP,
but documentation is found in a separate PR. This includes:
1. A pure python implementation of the ZoneInfo class
2. A C accelerated implementation of the ZoneInfo class
3. Tests with 100% branch coverage for the Python code (though C code
coverage is less than 100%).
4. A compile-time configuration option on Linux (though not on Windows)
Differences from the reference implementation:
- The module is arranged slightly differently: the accelerated module is
`_zoneinfo` rather than `zoneinfo._czoneinfo`, which also necessitates
some changes in the test support function. (Suggested by Victor
Stinner and Steve Dower.)
- The tests are arranged slightly differently and do not include the
property tests. The tests live at test/test_zoneinfo/test_zoneinfo.py
rather than test/test_zoneinfo.py or test/test_zoneinfo/__init__.py
because we may do some refactoring in the future that would likely
require this separation anyway; we may:
- include the property tests
- automatically run all the tests against both pure Python and C,
rather than manually constructing C and Python test classes (similar
to the way this works with test_datetime.py, which generates C
and Python test cases from datetimetester.py).
- This includes a compile-time configuration option on Linux (though not
on Windows); added with much help from Thomas Wouters.
- Integration into the CPython build system is obviously different from
building a standalone zoneinfo module wheel.
- This includes configuration to install the tzdata package as part of
CI, though only on the coverage jobs. Introducing a PyPI dependency as
part of the CI build was controversial, and this is seen as less of a
major change, since the coverage jobs already depend on pip and PyPI.
Additional changes that were introduced as part of this PR, most / all of
which were backported to the reference implementation:
- Fixed reference and memory leaks
With much debugging help from Pablo Galindo
- Added smoke tests ensuring that the C and Python modules are built
The import machinery can be somewhat fragile, and the "seamlessly falls
back to pure Python" nature of this module makes it so that a problem
building the C extension or a failure to import the pure Python version
might easily go unnoticed.
- Adjustments to zoneinfo.__dir__
Suggested by Petr Viktorin.
- Slight refactorings as suggested by Steve Dower.
- Removed unnecessary if check on std_abbr
Discovered this because of a missing line in branch coverage.
2020-05-16 05:20:06 -03:00
|
|
|
_zoneinfo
|
2017-06-10 16:58:42 -03:00
|
|
|
_decimal
|
|
|
|
_elementtree
|
|
|
|
_hashlib
|
|
|
|
_msi
|
|
|
|
_multiprocessing
|
|
|
|
_overlapped
|
|
|
|
_socket
|
|
|
|
_testbuffer
|
2017-09-08 00:10:29 -03:00
|
|
|
_testcapi
|
|
|
|
_testconsole
|
2017-06-10 16:58:42 -03:00
|
|
|
_testimportmultiple
|
2017-09-08 00:10:29 -03:00
|
|
|
_testmultiphase
|
|
|
|
_tkinter
|
2017-06-10 16:58:42 -03:00
|
|
|
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
|
2022-03-07 14:23:29 -04:00
|
|
|
Python wrapper for version 1.0.8 of the libbzip2 compression library
|
2017-06-10 16:58:42 -03:00
|
|
|
Homepage:
|
|
|
|
http://www.bzip.org/
|
|
|
|
_lzma
|
2017-06-16 00:08:51 -03:00
|
|
|
Python wrapper for version 5.2.2 of the liblzma compression library
|
2017-06-10 16:58:42 -03:00
|
|
|
Homepage:
|
2022-05-10 03:30:32 -03:00
|
|
|
https://tukaani.org/xz/
|
2017-06-10 16:58:42 -03:00
|
|
|
_ssl
|
2021-03-29 21:00:34 -03:00
|
|
|
Python wrapper for version 1.1.1k of the OpenSSL secure sockets
|
2017-09-08 00:10:29 -03:00
|
|
|
library, which is downloaded from our binaries repository at
|
|
|
|
https://github.com/python/cpython-bin-deps.
|
|
|
|
|
2017-06-10 16:58:42 -03:00
|
|
|
Homepage:
|
2022-05-10 03:30:32 -03:00
|
|
|
https://www.openssl.org/
|
2017-06-10 16:58:42 -03:00
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
Building OpenSSL requires Perl on your path, and can be performed by
|
|
|
|
running PCbuild\prepare_ssl.bat. This will retrieve the version of
|
|
|
|
the sources matched to the current commit from the OpenSSL branch
|
|
|
|
in our source repository at
|
|
|
|
https://github.com/python/cpython-source-deps.
|
|
|
|
|
|
|
|
To use an alternative build of OpenSSL completely, you should replace
|
|
|
|
the files in the externals/openssl-bin-<version> folder with your own.
|
|
|
|
As long as this folder exists, its contents will not be downloaded
|
|
|
|
again when building.
|
|
|
|
|
2017-06-10 16:58:42 -03:00
|
|
|
_sqlite3
|
2022-05-09 18:37:01 -03:00
|
|
|
Wraps SQLite 3.38.4, which is itself built by sqlite3.vcxproj
|
2017-06-10 16:58:42 -03:00
|
|
|
Homepage:
|
2022-05-10 03:30:32 -03:00
|
|
|
https://www.sqlite.org/
|
2017-06-10 16:58:42 -03:00
|
|
|
_tkinter
|
2017-09-08 00:10:29 -03:00
|
|
|
Wraps version 8.6.6 of the Tk windowing system, which is downloaded
|
|
|
|
from our binaries repository at
|
|
|
|
https://github.com/python/cpython-bin-deps.
|
|
|
|
|
2017-06-10 16:58:42 -03:00
|
|
|
Homepage:
|
2022-05-10 03:30:32 -03:00
|
|
|
https://www.tcl.tk/
|
2017-06-10 16:58:42 -03:00
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
Building Tcl and Tk can be performed by running
|
|
|
|
PCbuild\prepare_tcltk.bat. This will retrieve the version of the
|
|
|
|
sources matched to the current commit from the Tcl and Tk branches
|
|
|
|
in our source repository at
|
|
|
|
https://github.com/python/cpython-source-deps.
|
2017-06-10 16:58:42 -03:00
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
The two projects install their respective components in a
|
2017-06-10 16:58:42 -03:00
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
2017-06-16 00:08:51 -03:00
|
|
|
https://github.com/python/cpython-source-deps
|
|
|
|
and
|
|
|
|
https://github.com/python/cpython-bin-deps
|
|
|
|
via a Python script called "get_external.py", located in this directory.
|
|
|
|
If Python 3.6 or later is not available via the "py.exe" launcher, the
|
|
|
|
path or command to use for Python can be provided in the PYTHON_FOR_BUILD
|
|
|
|
environment variable, or get_externals.bat will download the latest
|
|
|
|
version of NuGet and use it to download the latest "pythonx86" package
|
|
|
|
for use with get_external.py. Everything downloaded by these scripts is
|
|
|
|
stored in ..\externals (relative to this directory).
|
2017-06-10 16:58:42 -03:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2017-09-08 00:10:29 -03:00
|
|
|
The get_externals.bat script is called automatically by build.bat
|
|
|
|
unless you pass the '-E' option.
|
2017-06-10 16:58:42 -03:00
|
|
|
|
|
|
|
|
|
|
|
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
|
2022-05-10 03:30:32 -03:00
|
|
|
https://docs.microsoft.com/en-us/cpp/build/profile-guided-optimizations
|
2017-06-10 16:58:42 -03:00
|
|
|
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)
|
2017-09-08 00:10:29 -03:00
|
|
|
* openssl (used by projects dependent upon OpenSSL)
|
2017-06-10 16:58:42 -03:00
|
|
|
* 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
|
2019-07-30 19:16:13 -03:00
|
|
|
for different configurations.
|