Des news en provenance de MAME:
J’espère que vous avez apprécié notre annonce du 1er avril. Maintenant que c’est passé, il est temps d’aborder les véritables changements à venir pour MAME. Nous mettons à jour la norme du langage de développement, passant de C++17 à C++20, et nous retirons la prise en charge de configurations obsolètes. Nous allons également réduire un peu la fréquence des sorties : il n’y aura plus de version presque chaque mois. Il n’y aura pas de sortie en avril ; la prochaine version arrivera vers la fin du mois de mai.
Résumé des exigences mises à jour :
- Un compilateur et une bibliothèque standard C++ offrant un niveau raisonnable de compatibilité C++20. GCC 11 sera la version minimale prise en charge. Vous pouvez également utiliser une version suffisamment récente de clang.
- Les versions Windows nécessiteront une installation mise à jour de Windows 10 ou plus récent. Microsoft a déjà arrêté le support standard de Windows 10, ainsi que de toutes les versions antérieures de Windows Home et Pro, et Windows 11 a déjà quatre ans.
- Le débogueur de MAME basé sur Qt nécessitera Qt 6.
Résumé des fonctionnalités supprimées :
- Le backend recompilé 32 bits x86 (i686). L’architecture x86‑64 existe depuis plus de vingt ans. Tous les principaux systèmes d’exploitation x86 la prennent en charge depuis longtemps, et le support du x86 32 bits est en train de disparaître.
- La prise en charge de la compilation sur OpenSolaris et autres systèmes UNIX System V. Il n’existe plus de distributions OpenSolaris activement développées, et les autres variantes System V UNIX n’ont plus de présence significative sur les systèmes de bureau.
- Les optimisations spécifiques pour les systèmes hôtes PowerPC. PowerPC et OpenPOWER n’ont actuellement aucune présence notable sur le marché desktop, et le projet Libre‑SOC visant à produire une implémentation OpenPOWER totalement libre et performante est au point mort.
- L’outil obsolète aueffectutil pour macOS. Cet outil n’a plus d’utilité avec le nouveau système audio de MAME, et il n’avait pas été mis à jour pour fonctionner avec les versions récentes de macOS.
- Les environnements MSYS2 précompilés avec outils de développement inclus. Nos environnements MSYS2 posent plusieurs problèmes que nous ne pouvons pas résoudre de manière réaliste.
Lisez la suite pour plus de contexte et de détails.
Nous avons décidé qu’il était temps de passer à la version suivante du standard C++ et de commencer à tirer parti des nouvelles fonctionnalités. Cela fait suffisamment longtemps pour que les bibliothèques et outils compatibles C++20 soient largement disponibles. Nous prendrons en charge la compilation avec GCC 11 et GNU libstdc++ 11 ou plus récent. Si vous utilisez clang pour compiler MAME, notez que clang 11 et 12 contiennent des bugs inacceptables dans leur implémentation de C++20, et que clang 13 peut planter lors de la compilation de certains éléments. Vous aurez donc peut‑être besoin d’une version assez récente de clang pour continuer à l’utiliser.
De même, Qt 6 est disponible dans MSYS2 et fourni depuis longtemps par toutes les grandes distributions Linux. Nous estimons que c’est le bon moment pour retirer la prise en charge de Qt 5.
En raison de l’augmentation de l’utilisation mémoire dans les versions récentes de GCC, et du retrait de clang et d’autres paquets LLVM du dépôt MSYS2 MINGW32, il n’est plus réaliste de créer des builds Windows 32 bits x86 de MAME. Les fonctionnalités liées au support du x86 32 bits sous Windows deviendront donc non maintenues. Comme le support du x86 32 bits est également en recul sur les autres systèmes d’exploitation, nous avons décidé que cela ne valait plus l’effort de maintenir des fonctionnalités spécifiques à cette architecture. Nous retirons en même temps les fonctionnalités spécifiques à PowerPC, devenues tout aussi difficiles à maintenir.
Nous allons passer à des builds Windows x86‑64 utilisant clang, la bibliothèque standard libc++, et la bibliothèque d’exécution Microsoft Universal CRT (UCRT). Cela permettra d’utiliser les mêmes outils et bibliothèques pour les versions x86‑64 et ARM.
Il est devenu évident que le support des environnements MSYS2 utilisant l’ancienne bibliothèque MSVCRT est en train d’être abandonné. Divers paquets sont retirés des dépôts au lieu d’être mis à jour. Il deviendra nécessaire de migrer vers un environnement utilisant la bibliothèque UCRT, c’est‑à‑dire UCRT64 ou CLANG64 pour le x86‑64, ou CLANGARM64 pour l’ARM 64 bits. Nos scripts de build prennent déjà en charge ces environnements sans effort supplémentaire.
Les environnements MSYS2 prépackagés que nous fournissons présentent plusieurs problèmes :
- Ils ne correspondent plus depuis longtemps aux versions exactes des paquets utilisés pour compiler les versions officielles de MAME, ce qui les rend inutiles pour reproduire ces builds.
- Ils sont mis à jour rarement. Cela rend les mises à jour du runtime MSYS2 ou des paquets inclus très risquées, car MSYS2 gère mal les sauts de versions multiples.
- Inclure tous les paquets nécessaires pour compiler MAME dans toutes les configurations supportées, ainsi que des outils de développement utiles, rendrait le téléchargement beaucoup trop volumineux. À l’inverse, omettre des paquets conduit les utilisateurs à rencontrer tous les problèmes liés aux mises à jour MSYS2 lorsqu’ils tentent d’ajouter eux‑mêmes les paquets manquants.
- Emballer des outils de développement ne fait pas partie de notre mission principale et prend du temps sur le développement de MAME.
Nous recommandons donc d’installer un environnement MSYS2 standard et d’installer les paquets nécessaires via le gestionnaire de paquets pacman. Nous listons les paquets requis dans notre documentation, et nos workflows Windows sur GitHub Actions montrent les paquets nécessaires de manière structurée.
Il y aura forcément quelques difficultés avec un changement majeur comme celui‑ci, mais nous pensons que c’est une étape nécessaire pour assurer la viabilité du développement de MAME sur le long terme.
Avec cette annonce, c’est désormais acté : le support du 32 bits touche à sa fin, et nos propres binaires compatibles Windows XP — qui n’était déjà plus officiellement pris en charge depuis des années — vont eux aussi disparaître d’ici peu.
