* group the (stateful) runtime globals into various topical structs
* consolidate the topical structs under a single top-level _PyRuntimeState struct
* add a check-c-globals.py script that helps identify runtime globals
Other globals are excluded (see globals.txt and check-c-globals.py).
Fix logic for retrying nuget.exe download with Python.
Add support for HOST_PYTHON variable.
Clear internal environment variables used in find_python.bat
Use HOST_PYTHON as the actual Python if it is recent enough.
Adds HOST_PYTHON variable to AppVeyor configuration
* bpo-30726: Fix elementtree warnings on Windows
Caused by usage of `getenv` which should be safe. And a few integer
truncations which should also be ok.
* bpo-30726: Don't ignore libexpat warnings which haypo intends to fix upstream
bpo-30726, bpo-29591: libexpat 2.2.1 of Modules/expat/ now uses
a winconfig.h configuration file which already defines:
* XML_NS
* XML_DTD
* BYTEORDER=1234
* XML_CONTEXT_BYTES=1024
* HAVE_MEMMOVE
Remove these defines from PCbuild/_elementtree.vcxproj to prevent
compiler warnings.
Co-Authored-By: Jeremy Kloth <jeremy.kloth@gmail.com>
The Windows build now depends on Python 3.6 to fetch externals, but it will be downloaded via NuGet (which is downloaded via PowerShell) if it is not available via `py -3.6`. This means the only thing that must be installed on a modern Windows box to do a full build of CPython with all extensions is Visual Studio.
Also fixes an outdated note about _lzma in PCbuild/readme.txt
* Improves test_underpth_nosite_file to reveal why it fails.
* Enable building with Windows 10 SDK.
* Fix WinSDK detection
* Fix initialization on Windows when a ._pth file exists.
* Fix tabs
* Adds comment about Py_GetPath call.
PEP 432 specifies a number of large changes to interpreter startup code, including exposing a cleaner C-API. The major changes depend on a number of smaller changes. This patch includes all those smaller changes.
* Adds lib.pyproj file to solution so that VS with Python support can open all the files in the standard library.
* Remove unexpected solution configuration.
* Remove lib.pyproj from solution to avoid memory issues on VS 2015.
Using a response file will eliminate the headache associated with batch argument/quote processing.
For example I unsucessfully compiled python with visualcpptools when specifying VSInstallDir in the batch file (cannot find vcruntime.h)
```batch
build.bat -p x64 -e -M --no-tkinter "/p:VCInstallDir=%VCInstallDir%"
```
but it build successfully when specifying it in a response file
msbuild.rsp:
```
/p:VCInstallDir=%VCInstallDir%
```
Use --short form of git hash. Use output from "git describe" for tag.
Expected outputs:
1. previous hg
2. previous git
3. updated git
Release (tagged) build:
1. Python 3.7.0a0 (v3.7.0a0:4def2a2901a5, ...
2. Python 3.7.0a0 (v3.7.0a0^0:05f53735c8912f8df1077e897f052571e13c3496, ...
3. Python 3.7.0a0 (v3.7.0a0:05f53735c8, ...
Development build:
1. Python 3.7.0a0 (default:41df79263a11, ...
2. Python 3.7.0a0 (master:05f53735c8912f8df1077e897f052571e13c3496, ...
3. Python 3.7.0a0 (heads/master-dirty:05f53735c8, ...
"dirty" means the working tree has uncommitted changes.
See "git help describe" for more info.
* Move all functions to call objects in a new Objects/call.c file.
* Rename fast_function() to _PyFunction_FastCallKeywords().
* Copy null_error() from Objects/abstract.c
* Inline type_error() in call.c to not have to copy it, it was only
called once.
* Export _PyEval_EvalCodeWithName() since it is now called
from call.c.
* Move all functions to call objects in a new Objects/call.c file.
* Rename fast_function() to _PyFunction_FastCallKeywords().
* Copy null_error() from Objects/abstract.c
* Inline type_error() in call.c to not have to copy it, it was only
called once.
* Export _PyEval_EvalCodeWithName() since it is now called
from call.c.
Zachary Ware
Steve Dower
Eric Snow
Victor Stinner
Serhiy Storchaka
Segev Finer
Charles
Ned Deily
Xiang Zhang
INADA Naoki