forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
PEP 756: The CPython 3.13 build system
- Loading branch information
1 parent
b05d5c6
commit 5fedc56
Showing
1 changed file
with
155 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,155 @@ | ||
PEP: 756 | ||
Title: The CPython 3.13 build system. | ||
Author: Erlend Egeberg Aasland <erlend@python.org>, | ||
Zachary Ware <zach@python.org> | ||
Status: Draft | ||
Type: Standards Track | ||
Created: 09-Oct-2023 | ||
Python-Version: 3.13 | ||
|
||
|
||
Abstract | ||
======== | ||
|
||
:pep:`755` summarized the problems with the CPython 3.12 build system. | ||
This PEP suggests a new build system be implemented for CPython 3.13, | ||
|
||
|
||
Motivation | ||
========== | ||
|
||
According to :pep:`755`, the biggest pain with the CPython 3.12 build system, | ||
is that consists of *two* hard-to-comprehend build systems: | ||
|
||
- The Windows build --- a collection of XML and BAT files | ||
- The \*nix build --- :file:`configure.ac` and :file:`Makefile.pre.in` | ||
|
||
Developers in the Windows camp find the GNU Autoconf code incomprehensible; | ||
developers in the \*nix camp find the XML files of the Windows build cryptic. | ||
|
||
Also according to :pep:`755`, | ||
the number one goal for a future build system is a unified build system. | ||
|
||
|
||
Rationale | ||
========= | ||
|
||
*TODO* | ||
|
||
|
||
Specification | ||
============= | ||
|
||
A build system will be implemented with the goals of :pep:`755` in mind: | ||
|
||
- a unified build system that works on all :pep:`11` supported platforms | ||
- correct and fast incremental builds | ||
- deterministic builds | ||
- it should be easy to constrain external dependencies | ||
- cross-compilation support | ||
- good quality documentation | ||
- an active community | ||
- being actively developed | ||
|
||
Contenders | ||
========== | ||
|
||
CMake | ||
----- | ||
|
||
CMake is implemented in C++, | ||
and is being actively developed as an open source project by Kitware | ||
under the BSD License 2. | ||
It has been around since 2000, and is currently at release 3.27.7. | ||
|
||
|
||
Meson | ||
----- | ||
|
||
Meson is implemented in Python, | ||
and is being actively developed as an open source project on GitHub | ||
under the Apache License 2.0. | ||
It has been around since 2013, and is currently at release 1.2.1. | ||
|
||
|
||
Bazel | ||
----- | ||
|
||
Bazel is implemented in Java, | ||
and is being actively developed as an open source project on GitHub by Google | ||
under the Apache License 2.0. | ||
It has been around since 2015, and is currently at release 6.0.0. | ||
|
||
|
||
Backwards Compatibility | ||
======================= | ||
|
||
A new build system will impose new bootstrapping constraints; | ||
this will affect how easy it will be to port Python to new architectures and platforms. | ||
A bootstrapping guide will be written for the devguide in order to mitigate this. | ||
|
||
|
||
Security Implications | ||
===================== | ||
|
||
*TODO* | ||
|
||
|
||
How to Teach This | ||
================= | ||
|
||
Documentation for core developers and contributors will be added to the docs and devguide. | ||
HowTo guides for specific use cases like deterministic builds and cross-building will be added. | ||
|
||
Most users, beginners included, are not not affected, | ||
as they are not expected to ever need to interface the build system. | ||
|
||
|
||
Reference Implementation | ||
======================== | ||
|
||
*TODO: Add GitHub links* | ||
|
||
|
||
Rejected Ideas | ||
============== | ||
|
||
Keep the current dual build system | ||
---------------------------------- | ||
|
||
Continuing to maintain the current dual build system will not harmonize | ||
with the most important desire amongst the core developers: a unified build system. | ||
|
||
The duality of the current build system is one of the biggest source of frustrations | ||
amongst core developers, contributors and distributors. | ||
|
||
|
||
Use a custom written build script | ||
--------------------------------- | ||
|
||
Instead of chosing an existing build system, | ||
implement the new build system as a collection of hand-written scripts. | ||
|
||
The additional overhead of desiging a specification for such a build system, | ||
implementing, maintaining, and documenting it would be considerable compared | ||
to using an existing build system that comes complete with an implementation, | ||
documentation, and a support community. | ||
|
||
|
||
Open Issues | ||
=========== | ||
|
||
Implement proof-of-concept build systems for the most promising contenders. | ||
|
||
|
||
Footnotes | ||
========= | ||
|
||
*TODO* | ||
|
||
|
||
Copyright | ||
========= | ||
|
||
This document is placed in the public domain or under the | ||
CC0-1.0-Universal license, whichever is more permissive. |