Ports and contacts¶

The table below lists relevant third-party projects, their maintainers, and links to information that’s relevant when triaging platform-specific issues. Officially supported platforms are also included when there is relevant information for them (beyond PEP 11), or to group similar platforms.

It is OK to @mention the listed GitHub usernames to draw maintainers’ attention or request their opinion on platform-specific issues. Maintainers must only be listed with their permission, and they may remove themselves at any time.

Third-party projects should only be listed if they benefit substantially more people than the maintainers.

Links should be for the port specifically (not the platform itself), and relevant for porting work and fixing platform-specific issues (no homepage/marketing links).

Porting to a new platform¶

Porting CPython to an entirely new platform is an adventure. If you try it, consider keeping notes – and updating this guide, if you find something that might be relevant to others. Since each platform is different, this guide can only give you a few rough tips.

The first step is to familiarize yourself with the development toolchain on the platform in question, notably the C compiler. Make sure you can compile and run a hello-world program using the target compiler.

Next, learn how to compile and run the Python interpreter on a platform to which it has already been ported; preferably Unix, but Windows will do, too. The build process for Python, in particular the Makefile 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, and others are only used in emergencies (for example, Python/getopt.c).

It is not recommended to start porting Python without at least a medium-level understanding of your target platform; how it is generally used, how to write platform-specific apps, and so on. Also, some Python knowledge is required, or you will be unable to verify that your port is working correctly.

On systems with a UNIX shell, run the included configure script. This should generate all required files, including a Makefile. If it does not, you will need to debug it (or reimplement it). Note that the script is generated from configure.ac using GNU Autotools. (CPython pins a specific version for reproducibility, but other versions may work fine.)

The main files that configure generates – and which you might want to check – are:

• A pyconfig.h file tailored for your platform. If you need to create this manually, start with pyconfig.h.in, read the comments, and turn on definitions that apply to your platform.

• A config.c file, which lists the built-in modules you support. Until you get dynamic extension loading to work, all compiled modules you need to import will need to be listed here. The file is generated from Modules/config.c.in.

• A Makefile with instructions to put everything together. If one isn’t generated, try compiling all the *.c files, and fix the errors – or omit files that don’t look important. For example, forget about the posix module (Modules/posixmodule.c) in the beginning: don’t compile it, and comment it out of the config.c file.

Keep working on it until you get a >>> prompt. You may have to disable the importing of site.py by passing the -S option. When you have a prompt, bang on it until it executes very simple Python statements.

At some point you will want to use the os module; this is the time to start thinking about what to do with the posix module. It is okay to simply comment out functions in the posix module that cause problems; the remaining ones will be quite useful. You can use the same approach for other modules too, of course.

Before you are done, it is highly recommended to run the Python regression test suite, as described in Running and writing tests. You will probably need to skip tests that do not make sense; for inspiration look at how that’s done for the WASI platform.