This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: [CMake] It's 2020, where is CMake?
Type: enhancement Stage: resolved
Components: Build Versions: Python 3.10
Status: closed Resolution: postponed
Dependencies: Superseder:
Assigned To: Nosy List: TheUltimatePineapple, chris.jerdonek, christian.heimes, ned.deily, pmpp, remi.lapeyre
Priority: normal Keywords:

Created on 2020-05-23 14:56 by TheUltimatePineapple, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (7)
msg369724 - (view) Author: TheUltimatePineapple (TheUltimatePineapple) Date: 2020-05-23 14:56
The current CPython build system is antiquated and makes cross-platform builds difficult (in my experience). There have been unofficial CMake implementations but they are either outdated, abandoned or just unusable.

Adopting CMake has many benefits, here are few:

1. Simplifies cross-platform builds and inclusion of CPython in other projects as subdirectory/subproject.

2. Automatically generated builds for any CMake supported OS'es, no need to maintain an unique build system for each OS, only the CMake script.

3. Faster. Just the configuration process in current build system for Unix is super slow, making testing changes slow and painful.
msg369725 - (view) Author: pmp-p (pmpp) * Date: 2020-05-23 15:10
Hi, I'm always curious about others experiences : why would you need cross-platform building for any of the officially supported platforms ?

Also on some random unsupported platforms that require cross-compilation like maybe android, wasm or other uncommon posix, cmake is maybe not yet fully ready. So it may be easier to hack the old system if not alternative is present.
msg369733 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-05-23 17:54
Can you point to specific issues with the current build system?

It seems to me that for 1. it will only make it easier for projects that use CMake, 2. the build system is not the only part needed to support a new OS and for 3. I've not found Python to be particularly slow to build for such a large program. You may want to look at ccache if you want to speed you build process (I'm not using it on this computer and it's still quite fast, Make will only rebuild the appropriate object files already unless you explicitly clean them).

Before making large changes to the build system, you should open a thread on the python-ideas mailing list, there was some discussion about this a few years back but maybe now that Python2 is gone it would be easier to make this change?
msg369738 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2020-05-23 19:21
How about you start with a PEP that compares our current build system with CMake and explores if CMake is a viable option? Is CMake supported on platforms like Solaris, HP-UX, VxWorks? Or are there better options for a new build system for CPython, for example Meson? After all Meson is written in Python and used by large projects like, Wayland, major parts of Gnome, systemd, and more.

PS: I find your phrasing and choice of words aggressive, condescending, patronizing. Please turn it down a nudge.
msg369740 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2020-05-23 19:36
This was discussed a bit last December 2019 here ("Is there prior discussion around the build system of CPython itself?"):
msg370866 - (view) Author: TheUltimatePineapple (TheUltimatePineapple) Date: 2020-06-07 02:40
For me CPython has caused a lot of pain without having CMake.

I have to manually compile CPython on each OS I want to support, having to fix the quirks on each build system and I have keep the built linkable blobs in my project which increases the repo size.

It seems though the people here are so old-fashioned they don't see the point in CMake ¯\_(ツ)_/¯

I don't think I can keep CPython adopted in my engine if it keeps being this way, I'll have to look into alternate scripting languages which don't rely on antiquated build systems.
msg370871 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-06-07 03:41
Thanks for your suggestion but changing build systems is a *huge* undertaking for cPython thanks to the many different platforms that we have added support to over the years and the many, many customizations that have been made.  cmake would certainly be one option; starting from scratch with modern autotools another. And there are many such others. But this is way beyond the scope of a standard feature enhancement. In fact, there have been some discussions around the PSF funding one or more persons to reimplement our Unix-y build system (note there is a separate build system for Windows platforms). As Christian suggests, one concrete step towards getting a new build system would be to write a detailed PEP and then discussing in the ideas and/or core-workflow groups; another would be to help secure funding.  But without first steps like that, there won't be anything served by further discussions here. So I'm closing this issue. It could be re-opened in the future once there is consensus on an approach and implementation resources are identified.
Date User Action Args
2022-04-11 14:59:31adminsetgithub: 84920
2020-06-07 03:41:21ned.deilysetstatus: open -> closed

nosy: + ned.deily
messages: + msg370871

resolution: postponed
stage: resolved
2020-06-07 02:41:00TheUltimatePineapplesetmessages: + msg370866
2020-05-23 19:36:53chris.jerdoneksetnosy: + chris.jerdonek
messages: + msg369740
2020-05-23 19:21:10christian.heimessetnosy: + christian.heimes
messages: + msg369738
2020-05-23 17:54:45remi.lapeyresetnosy: + remi.lapeyre
messages: + msg369733
2020-05-23 15:10:01pmppsetnosy: + pmpp
messages: + msg369725
2020-05-23 14:56:08TheUltimatePineapplecreate