…es (#1222)liblzma is missing from pcbuild.sln. This causes the build of _lzma to fail when building the solution and not using build.bat.

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 version6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64bit platforms.  Using this directory requires an installation ofMicrosoft Visual C++ 2015 (MSVC 14.0) of any edition.  The specificrequirements are as follows:Visual Studio Express 2015 for DesktopVisual 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 buildsVisual 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 VisualStudio, select the desired combination of configuration and platform,then build with "Build Solution".  You can also build from the commandline using the "build.bat" script in this directory; see below fordetails.  The solution is configured to build the projects in the correctorder.The solution currently supports two platforms.  The Win32 platform isused to build standard x86-compatible 32-bit binaries, output into thewin32 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:    python37_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 makebuilding Python on Windows simpler.  This script will use the env.batscript to detect one of Visual Studio 2015, 2013, 2012, or 2010, any ofwhich may be used to build Python, though only Visual Studio 2015 isofficially supported.By default, build.bat will build Python in Release configuration forthe 32-bit Win32 platform.  It accepts several arguments to changethis behavior, try `build.bat -h` to learn more.C Runtime---------Visual Studio 2015 uses version 14 of the C runtime (MSVCRT14).  Theexecutables no longer use the "Side by Side" assemblies used in previousversions of the compiler.  This simplifies distribution of applications.The run time libraries are available under the VC/Redist folder of yourVisual Studio distribution. For more info, see the Readme in theVC/Redist folder.Sub-Projects------------The CPython project is split up into several smaller sub-projects whichare managed by the pcbuild.sln solution file.  Each sub-project isrepresented by a .vcxproj and a .vcxproj.filters file starting with thename of the sub-project.  These sub-projects fall into a few generalcategories:The following sub-projects represent the bare minimum required to builda functioning CPython interpreter.  If nothing else builds but these,you'll have a very limited but usable python.exe:pythoncore    .dll and .libpython    .exeThese sub-projects provide extra executables that are useful for runningCPython in different ways:pythonw    pythonw.exe, a variant of python.exe that doesn't open a Command    Prompt windowpylauncher    py.exe, the Python Launcher for Windows, seehttp://docs.python.org/3/using/windows.html#launcherpywlauncher    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.pyThese are miscellaneous sub-projects that don't really fit the othercategories:_freeze_importlib    _freeze_importlib.exe, used to regenerate Python\importlib.h after    changes have been made to Lib\importlib\_bootstrap.pypython3dll    python3.dll, the PEP 384 Stable ABI dllxxlimited    builds an example module that makes use of the PEP 384 Stable ABI,    see Modules\xxlimited.cThe following sub-projects are for individual modules of the standardlibrary 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_testimportmultiplepyexpatselectunicodedatawinsoundThe following Python-controlled sub-projects wrap external projects.Note that these external libraries are not necessary for a workinginterpreter, but they do implement several major features.  See the"Getting External Sources" section below for additional informationabout getting the source for building these libraries.  The sub-projectsare:_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.2k 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 fromhttp://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 PCbuild\get_externals.bat method    for getting sources, it also downloads a version of NASM which the    libeay/ssleay sub-projects use.    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 fromhttp://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.14.2.0, which is itself built by sqlite3.vcxproj    Homepage:http://www.sqlite.org/_tkinter    Wraps version 8.6.6 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 projectsPython doesn't control, and as such a little more work is required inorder to download the relevant source files for each project before theycan be built.  However, a simple script is provided to make this aspainless as possible, called "get_externals.bat" and located in thisdirectory.  This script extracts all the external sub-projects fromhttp://svn.python.org/projects/externalvia Subversion (so you'll need svn.exe on your PATH) and places themin ..\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 MSBuildas the values of certain properties in order for the build solution tofind them.  This is an advanced topic and not necessarily fullysupported.The get_externals.bat script is called automatically by build.bat whenyou pass the '-e' option to it.Profile Guided Optimization---------------------------The solution has two configurations for PGO. The PGInstrumentconfiguration must be built first. The PGInstrument binaries are linkedagainst a profiling library and contain extra debug information. ThePGUpdate configuration takes the profiling data and generates optimizedbinaries.The build_pgo.bat script automates the creation of optimized binaries.It creates the PGI files, runs the unit test suite or PyBench with thePGI python, and finally creates the optimized files.Seehttp://msdn.microsoft.com/en-us/library/e7k32f4k(VS.140).aspxfor more on this topic.Static library--------------The solution has no configuration for static libraries. However it iseasy to build a static library instead of a DLL. You simply have to setthe "Configuration Type" to "Static Library (.lib)" and alter thepreprocessor macro "Py_ENABLE_SHARED" to "Py_NO_ENABLE_SHARED". You mayalso 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 PropertyManager (View -> Other Windows -> Property Manager) but should becarefully 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 eachproject, with some projects overriding certain specific values. The GUIdoesn't always reflect the correct settings and may confuse the userwith false information, especially for settings that automatically adaptfor diffirent configurations.