CPython opens the stdlib zip with its own stdio, so it needs a real path.
On the desktop res:// is a directory and globalize_path() is enough; in an
exported build res:// is inside the PCK, which nothing outside Godot reads.
make_stdlib_zip.py now also writes <out>.sha256
mtpython_stdlib_project copies python27.zip + .sha256 into project/
(gitignored), and both export presets' include_filter lists them, so
they enter the PCK — checked with --export-pack
extension/src/python_stdlib.{h,cpp} (Metin2Python.stdlib_path in
GDScript): reads the bytes out of the PCK, writes
user://python27.zip.part, hashes the file as written against the
shipped digest, then renames. A sandbox copy is reused only when it
matches, so a first start killed mid-copy and a zip replaced by a new
build both re-stage instead of feeding zipimport a torn file.
PythonHost::SetDefaultStdLibPath / DefaultStdLibPath() answer with that
path ($MT_PYTHON_STDLIB still wins). python_stdlib.cpp is the only unit
that knows res:// / user://; port_platform stays godot-free.
Also fixes the Windows gate, which step 3b broke: without mtpython the
MinGW build compiled UserInterface/StdAfx.h (it includes ScriptLib/StdAfx.h,
as the original PCH does). port/CMakeLists.txt excludes that header and
PythonPackModule.cpp with ScriptLib, and platform/CMakeLists.txt excludes
platform/ScriptLib/ the same way.
Not done: on-device staging. The macOS test drives the mobile path with
force_stage=true, and nothing in the app boot calls it yet — the
interpreter only starts in the process with 2V0.
gates: python_stdlib_test.gd PASS (in-place path, staging, sha256, bytes
equal res://, no .part, ZIPReader finds encodings/__init__.py, no re-copy
on a second call, corrupted copy re-staged) · macOS ctest 27/27 ·
mingw + android + ios port_platform compile clean · port_map.py check 0
errors · key leak check 8/8 none.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
step 3a — 标准库:
tools/py_embed/make_stdlib_zip.py packs the vendored Lib/ into
<build>/python27.zip (397 modules, 6876547 bytes, ZIP_STORED — the zlib
module is trimmed out of our CPython, so zipimport cannot inflate).
The mtpython_stdlib target builds it; py_embed_test and the launcher test
both run against it.
platform/ScriptLib/PythonHost sets the embedding flags before
Py_Initialize and, after it, puts the zip on sys.path and re-registers
encodings.search_function with codecs — 2.7 builds the codec registry
once, at startup, so replacing sys.path afterwards needs it back.
step 3b — pack 模块:
UserInterface/PythonPackModule.cpp copied verbatim; packExist/packGet/
initpack read root/ and uiscript/ through CEterPackManager, i.e. through
asset_io. The CHINA_CRYPT_KEY block in that unit is CAccountConnector's
and is kept #if 0 until the login slice (2V1). UserInterface/StdAfx.h is
a documented partial mirror — the original is the whole client's PCH.
The launcher test now runs initpack() as RunMainScript does (its first
line), reads system.py / uiscript / locale text back out of the packs, and
confirms cp1252 decoding works off the zip. system.py still stops at
"No module named app" — the C++ modules are the 2V0 slice.
gates: port_map.py check 0 errors · key leak check 8/8 none · macOS ctest
27/27 · android + ios port_platform compile clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link mtpython into port_logic and copy 40250's ScriptLib launcher across:
PythonLauncher, PythonUtils and PythonMarshal, plus the 12 forwarding headers
that make its `#include <Python-2.7/*>` lines compile unchanged. symtable.h
forward-declares mod_ty rather than including Python-ast.h, whose one-word
macros (Delete, Module, Set, Print) collide with EterLib/Pool.h — the same
clash 40250 sidestepped by commenting out PySymtable_Build.
Two `// PORT:` edits: `unsigned char(val)` is an MSVC extension (PythonUtils.cpp,
twice), and PyObject_AsCharBuffer wants a Py_ssize_t* (TraceFunc).
port_python_launcher_test drives the launcher in the order UserInterface.cpp
does (:241-434): Create(), __DEBUG__/__COMMAND_LINE__, TRUE/FALSE, a CRLF script
through RunMemoryTextFile, a .pyc through RunCompiledFile, then RunFile reading
system.py out of the real pack. It stops at `ImportError: No module named app`,
i.e. the first C++ module RunMainScript registers — that is the 2V0 slice, and
the stdlib behind it is step 3. The host flags (Py_NoSiteFlag and friends) sit
in the test for now; step 3 moves them into the platform layer.
port-map statuses are set only for what the test actually executes: 10 of 12
launcher functions and 4 of 11 marshal ones (the small-.pyc path delegates to
CPython's own reader, so the ported r_object stays unreached). PythonUtils
compiles but nothing calls it until the binding modules arrive, so it stays TODO.
Windows has no mtpython yet, so port_logic drops ScriptLib and the shims there.
Tests: macOS ctest 27/27 incl. port.python_launcher; port_logic (with ScriptLib)
also compiles for android arm64 (NDK API 24) and ios arm64.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The embedded 40250 script layer needs its own interpreter on five platforms.
2.7 is end-of-life, so nothing can be fetched from the target SDKs and the
source is vendored (official 2.7.18 tarball, trimmed to 25MB; Lib/ stays for
step 3's python27.zip).
cpython-2.7.18/CMakeLists.txt builds one `mtpython` static library from exactly
the 133 objects the reference libpython2.7.a contains, off by default behind
-DMTGODOT_EMBED_PYTHON=ON. The source list and the built-in module table
(config/config.c, 39 entries) are shared; pyconfig.h is a probe result and is
not, so each platform keeps its own under config/<platform>/, regenerated by
tools/py_embed/gen_pyconfig.sh and checked against the shared table.
Three vendor patches, documented in docs/THIRD-PARTY.md: configure/configure.ac
learn arm64 on macOS, and posixmodule.c undefines the process-control calls it
hard-defines past pyconfig.h when building for iOS.
macOS (ctest python.embed: every builtin imports, codecs and pickle work off the
vendored Lib/), Android arm64 and iOS arm64 build. Linux needs a Linux host and
Windows needs a MinGW-vs-MSVC decision; both are noted for step 4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
