shenleiandClaude Opus 5
5fad769ee8
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>
42 lines
1.9 KiB
Plaintext
42 lines
1.9 KiB
Plaintext
Q. I want to port Python to a new platform. How do I begin?
|
|
|
|
A. I guess the two things to start with is to familiarize yourself
|
|
with are the development system for your target platform and the
|
|
generic build process for Python. Make sure you can compile and run a
|
|
simple hello-world program on your target platform. Make sure you can
|
|
compile and run the Python interpreter on a platform to which it has
|
|
already been ported (preferably Unix, but Mac or Windows will do,
|
|
too).
|
|
|
|
I also would never start something like this without at least
|
|
medium-level understanding of your target platform (i.e. how it is
|
|
generally used, how to write platform specific apps etc.) and Python
|
|
(or else you'll never know how to test the results).
|
|
|
|
The build process for Python, in particular the Makefiles in the
|
|
source distribution, will give you a hint on which files to compile
|
|
for Python. Not all source files are relevant -- some are platform
|
|
specific, others are only used in emergencies (e.g. getopt.c). The
|
|
Makefiles tell the story.
|
|
|
|
You'll also need a pyconfig.h file tailored for your platform. You can
|
|
start with pyconfig.h.in, read the comments and turn on definitions that
|
|
apply to your platform.
|
|
|
|
And you'll need a config.c file, which lists the built-in modules you
|
|
support. Start with Modules/config.c.in.
|
|
|
|
Finally, you'll run into some things that aren't supported on your
|
|
target platform. Forget about the posix module for now -- simply take
|
|
it out of the config.c file.
|
|
|
|
Bang on it until you get a >>> prompt. (You may have to disable the
|
|
importing of "site.py" by passing the -S option.)
|
|
|
|
Then bang on it until it executes very simple Python statements.
|
|
|
|
Now bang on it some more. At some point you'll want to use the os
|
|
module; this is the time to start thinking about what to do with the
|
|
posix module. It's okay to simply #ifdef out those functions that
|
|
cause problems; the remaining ones will be quite useful.
|