* fix: pin the Python that builds CPython on Windows
CPython's build needs a Python to run its own build scripts. Without a local
Python 3.10-3.13, find_python.bat installs the newest pythonx86 from nuget.
That became 3.15.0 on 2026-10-09, and 3.15 removed
SourceFileLoader.load_module, which 3.12's makeopcodetargets.py calls:
AttributeError: 'SourceFileLoader' object has no attribute 'load_module'
Download Python 3.13.16 from nuget.org as its own dependency, with a hash
(pythonarm64 on ARM64 hosts, pythonx86 elsewhere), and pass it to PCbuild as
PYTHON, which find_python.bat takes before any other Python. PYTHONHOME and
PYTHONPATH are dropped from that step, since PCbuild runs the scripts
without -E. DEP_PYTHON_HOST points at an existing Python 3.10-3.13 instead,
for machines that cannot reach nuget.org.
Drop 01-windows-nuget.patch. It fixed the dead nuget.exe download link in
find_python.bat, and that fallback is never reached now. Existing deps trees
keep working: with no patch command, ExternalProject skips the patch step
instead of re-applying the patch to patched sources.
* fetch externals separately
---------
Co-authored-by: yw4z <ywsyildiz@gmail.com>
* fix: hide symbols of the bundled static openssl
* fix: hide the bundled static OpenSSL symbols on Linux
* fix: relink _ssl/_hashlib when OpenSSL recipe changes
Building deps with Xcode 27 on macOS 26 failed at the Python install step,
and a libpython built with Xcode 27 segfaulted on macOS 12-26 whenever a
plugin started a subprocess.
VS 2026's ARM64 code generator needs about 27 GB for
_PyUnicode_ToNumeric, a switch with 1951 cases in
Objects/unicodetype_db.h; the same file takes under 1 GB on x64. The
16 GB CI runner has an 18.9 GB commit limit and only gets through when
Windows grows the pagefile on the temp disk in time, so cold arm64
dependency builds fail at random with C1002 "compiler is out of heap
space". build_release_vs.bat returns 0 on failure, so the job still
reports success and the incomplete dependencies are cached.
A property sheet compiles that one file with optimisation off on arm64;
the rest stays whole-program optimised and x64 is unchanged.
MSBuild reads it from PCbuild/msbuild.rsp, which is now written at
configure time and copied in, so a checkout path with spaces works too.
git config wrote core.autocrlf into the repository git init creates in the
extracted CPython source. Nothing outside deps/build reads that repository, so
the setting was already contained.
-c applies the override to the one invocation instead, so no repository config is
written at all. It cannot reuse PATCH_CMD, so the shared flags are spelled out here.
git apply inherits the caller's configuration, so under core.autocrlf=input it
rewrites the patched PCbuild/find_python.bat to LF. cmd.exe cannot resolve goto
labels in an LF batch file, so CPython's build fails with "The system cannot
find the batch label specified - begin_search" and then "Cannot locate
python.exe on PATH or as PYTHON variable".
git init already runs in the extracted source, so setting core.autocrlf on the
repository it creates is enough, without touching the shared PATCH_CMD.
