Le guide de compilation de CPython sur macOS
Dépôt source de CPython, l'implémentation de référence du langage Python et l'interpréteur que la plupart des gens exécutent lorsqu'ils utilisent Python.
En bref
- De quoi s’agit-il ?
- Ce que le README macOS de python/cpython documente à propos des compilateurs, des binaires universels, des installations framework et des applications fournies.
- À qui s’adresse-t-il ?
- La licence accompagnant CPython est la Python Software Foundation License Version 2, qui accorde une licence non exclusive, libre de redevance et mondiale pour utiliser, reproduire et distribuer Python, et exige que les œuvres dérivées incluent un résumé des modifications. La licence fournit le logiciel en l'état (AS IS), sans aucune garantie, et ne dit rien sur la sécurité, le support ou la maintenance.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
La place du README macOS dans CPython
Le dépôt python/cpython est l'implémentation CPython du langage de programmation Python, décrit dans les métadonnées du dépôt comme "The Python programming language". Le fichier Mac/README.rst est la partie de la documentation spécifique à macOS. Il couvre les compilateurs avec lesquels les développeurs principaux testent, les arguments de configure qui contrôlent les builds framework et binaires universels, les applications fournies avec une installation framework, la création d'une distribution binaire, la désinstallation d'une installation framework et l'utilisation du weak linking pour cibler d'anciennes versions de déploiement. Le dépôt compte 74 165 étoiles et 35 137 forks sur GitHub, avec 9 499 problèmes ouverts, mais le README lui-même ne discute ni de la santé du projet ni des processus de contribution.
Prise en charge des compilateurs sur macOS
Les développeurs principaux testent principalement les builds sur macOS avec les outils de compilation d'Apple, soit Xcode, soit les Command Line Tools. Le README indique que seul un build avec un compilateur incluant un SDK ciblant le système d'exploitation de la machine de build est pris en charge, c'est-à-dire la version de Xcode fournie avec cette version du système ou une version plus récente. Pour macOS 12, cela signifie Xcode 13 et Xcode 14 (ou les Command Line Tools correspondants). La compilation avec d'autres compilateurs, comme GCC, fonctionne probablement, mais n'est pas activement prise en charge. Le README ne précise pas quelles versions de Xcode correspondent aux versions de macOS postérieures à 12, et ne documente pas non plus comment les builds avec des toolchains non Apple sont vérifiés.
Les binaires universels et leurs variantes d'architecture
Un build de binaire universel de Python contient du code objet pour plus d'une architecture de CPU, combiné dans un seul exécutable ou une seule bibliothèque qui s'exécute à la vitesse native sur chaque architecture prise en charge. Les fichiers universels ont été introduits dans macOS 10.4 pour ajouter la prise en charge d'Intel aux machines PowerPC existantes. La prise en charge de PPC a été supprimée dans macOS 10.7 et celle d'Intel 32 bits dans macOS 10.15, de sorte que macOS actuel ne prend en charge qu'une seule architecture d'exécution, Intel 64 bits (x86_64), arm64 arrivant via la variante universal2. L'option de configure --enable-universalsdk active un build universel et --with-universal-archs sélectionne la variante : universal2 (arm64, x86_64), intel (i386, x86_64), intel-32 (i386), intel-64 (x86_64), 32-bit (ppc, i386), 3-way (i386, x86_64, ppc), 64-bit (ppc64, x86_64) ou all (ppc, ppc64, i386, x86_64). Le README comprend un tableau des combinaisons SDK et Xcode qui prennent en charge quelles variantes, du SDK 10.4u avec Xcode 2 ne prenant en charge que 32-bit, aux SDK 10.15 et ultérieurs ne prenant en charge que intel-64, jusqu'aux SDK 11.0 et ultérieurs prenant en charge universal2.
Les builds framework
Un build framework crée un Python.framework plutôt qu'une installation Unix traditionnelle. La principale raison de choisir cette option est de créer des programmes GUI en Python : à l'exception des toolkits basés sur X11/XDarwin, tous les programmes GUI doivent s'exécuter à partir d'un bundle d'application macOS (.app), et un framework rend cela possible. Les frameworks placent également les éléments liés à Python à seulement deux endroits, /Library/Framework/Python.framework et /Applications/Python <VERSION>, ce qui simplifie la suppression. Les utilisateurs sans privilèges administrateur peuvent installer une distribution binaire dans leur répertoire personnel sans recompilation. La séquence de build est ./configure --enable-framework, make et make install. L'installation à un autre endroit, comme $HOME/Library/Frameworks, place les applications dans $HOME/Applications/Python-<VERSION> et les outils en ligne de commande dans $HOME/bin. Le README note que le build framework installe également les parties pertinentes du sous-arbre Mac via la cible installmacsubtree.
Les applications fournies
Une installation framework comprend trois types de programmes. IDLE.app est un environnement de développement intégré avec un éditeur et un débogueur. Python Launcher.app gère les double-clics sur les fichiers .py, .pyc et .pyw : pour les deux premiers, il ouvre une fenêtre de terminal et exécute le script avec le Python normal en ligne de commande ; pour les fichiers .pyw, il exécute le script dans l'interpréteur Python.app afin que le script puisse faire du travail GUI. Maintenir la touche Option enfoncée tout en faisant glisser ou en double-cliquant sur un script permet de définir des options d'exécution, qui peuvent également être définies de manière persistante via la boîte de dialogue des préférences de Python Launcher. Le programme pythonx.x exécute des scripts Python depuis la ligne de commande. Auparavant, des alias de compatibilité, dont pythonwx.x, étaient également installés, mais depuis 3.4.0, ces alias ne sont plus installés. Le README ne documente pas ce que fait l'application d'assistance cachée Python.app au-delà de son rôle d'interpréteur pour les scripts .pyw.
Créer une distribution binaire
Pour créer une distribution binaire, le README renvoie au script Mac/BuildScript/build-installer.py. Le script télécharge et compile un certain nombre de bibliothèques tierces, configure et compile un Python framework, l'installe, crée les fichiers de package d'installateur et les regroupe dans une image DMG. Il compile également une copie HTML de la documentation Python pour cette version, destinée à être incluse dans le framework. Le script compile un binaire universel, il doit donc être exécuté sur macOS 10.4 ou ultérieur avec Xcode 2.1 ou ultérieur, bien que le processus de compilation ait des dépendances non disponibles par défaut avec macOS 10.4. Le README conseille qu'il est plus sûr de compiler sur un système exécutant la version minimale de macOS prise en charge, et que les exécutables, bibliothèques partagées et bundles .so résultants doivent être soigneusement examinés et testés pour vérifier les dépendances de liaison dynamique. La compilation s'exécute de manière isolée dans /tmp/_py, donc elle n'utilise pas le répertoire de build normal et n'installe pas dans /. Le script doit être exécuté depuis le répertoire BuildScript et accepte des arguments de ligne de commande documentés par --help.
Désinstallation et weak linking
macOS ne fournit pas de désinstalleur central pour une installation framework. La suppression est manuelle : le framework lui-même dans /Library/Frameworks/Python.framework, les applications dans /Applications/Python X.Y, et les liens symboliques dans /usr/local/bin, qui pointent tous vers des fichiers du répertoire Versions/X.Y/bin du framework. Si l'on supprime une version d'un framework multi-versions, le lien symbolique Versions/Current doit être ajusté pour pointer vers une version installée. Le README couvre également le weak linking : CPython peut être compilé avec le dernier SDK tout en ciblant un déploiement sur macOS 10.9, via le weak linking de symboles introduits dans macOS 10.10 ou ultérieur. Cela nécessite la toolchain de compilateur d'Apple sur macOS 10.13 ou ultérieur. L'implémentation utilise une macro HAVE_<FUNCTION>_RUNTIME qui doit être la seule expression d'une instruction if. Le README ne couvre pas les instructions de compilation pour Windows ou Linux, et ne discute ni des performances, ni de la sécurité, ni du langage Python lui-même au-delà des sujets de compilation macOS.
Contrôle pratique de cpython
Sur macOS, suivre `./configure`, `make` et `make test`, puis utiliser `configure --enable-framework` seulement dans un répertoire de build dédié. Pour un binaire universel, contrôler `--enable-universalsdk` et `--with-universal-archs`; pour la distribution, inspecter les dépendances de `Mac/BuildScript/build-installer.py` et les bundles produits.
Conclusion éditoriale
La licence accompagnant CPython est la Python Software Foundation License Version 2, qui accorde une licence non exclusive, libre de redevance et mondiale pour utiliser, reproduire et distribuer Python, et exige que les œuvres dérivées incluent un résumé des modifications. La licence fournit le logiciel en l'état (AS IS), sans aucune garantie, et ne dit rien sur la sécurité, le support ou la maintenance.
Notes de la communauté