mirror of
https://github.com/python/cpython.git
synced 2025-08-15 22:30:42 +00:00
4c86cb31e2
svn+ssh://pythondev@svn.python.org/python/trunk ........ r78859 | georg.brandl | 2010-03-12 10:57:43 +0100 (Fr, 12 Mär 2010) | 1 line Get rid of backticks. ........ r78860 | georg.brandl | 2010-03-12 11:02:03 +0100 (Fr, 12 Mär 2010) | 1 line Fix warnings from "make check". ........ r78952 | georg.brandl | 2010-03-14 10:55:08 +0100 (So, 14 Mär 2010) | 1 line #8137: add iso-8859-16 to the standard encodings table. ........ r79168 | georg.brandl | 2010-03-21 10:01:27 +0100 (So, 21 Mär 2010) | 1 line Fix some issues found by Jacques Ducasse on the docs list. ........ r79169 | georg.brandl | 2010-03-21 10:02:01 +0100 (So, 21 Mär 2010) | 1 line Remove the "built-in objects" file. It only contained two paragraphs of which only one contained useful information, which belongs in the ref manual however. ........ r79173 | georg.brandl | 2010-03-21 10:09:38 +0100 (So, 21 Mär 2010) | 1 line Document that GzipFile supports iteration. ........ r79176 | georg.brandl | 2010-03-21 10:17:41 +0100 (So, 21 Mär 2010) | 1 line Introduce copy by slicing, used in later chapters. ........ r79178 | georg.brandl | 2010-03-21 10:28:16 +0100 (So, 21 Mär 2010) | 1 line Clarify that for shell=True, the shell PID will be the child PID. ........ r79179 | georg.brandl | 2010-03-21 10:37:54 +0100 (So, 21 Mär 2010) | 1 line Mention inefficiency of lists as queues, add link to collections.deque discussion. ........ r79181 | georg.brandl | 2010-03-21 10:51:16 +0100 (So, 21 Mär 2010) | 1 line Update os.kill() emulation example for Windows to use ctypes. ........ r79184 | georg.brandl | 2010-03-21 10:58:36 +0100 (So, 21 Mär 2010) | 1 line Update text for newest US DST regulation. The sample file already has the calculation right. ........ r79185 | georg.brandl | 2010-03-21 11:02:47 +0100 (So, 21 Mär 2010) | 1 line Include structmember.h correctly. ........ r79192 | georg.brandl | 2010-03-21 12:50:58 +0100 (So, 21 Mär 2010) | 1 line Remove leftover word. ........ r79212 | georg.brandl | 2010-03-21 20:01:38 +0100 (So, 21 Mär 2010) | 1 line Fix plural. ........
41 lines
1.9 KiB
Text
41 lines
1.9 KiB
Text
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.
|