Construire PostgreSQL avec Meson

29 sept 2022 - 7 minutes de lecture

Alors que la version 15 de PostgreSQL se prépare à sortir dans les prochains jours, le groupe de développement du projet communautaire ont intégré leurs récents travaux pour accélérer les tâches d’automatisation et de compilation à l’aide du système de construction Meson.

Ce chantier n’est pas anodin et redessine les contours de l’écosystème du moteur de bases de données open-source le plus avancé au monde. Depuis sa forme libre publiée en 1998, PostgreSQL repose sur des solutions robustes et éprouvées, mais de plus en plus complexes à maintenir pour les nouvelles générations de contributeur·rices. En proposant de se tourner vers un logiciel comme Meson, ces amoureux et amoureuses du libre se tournent résolument vers l’avenir.

En finir avec autoconf

Un système de construction ou build system (ne vous y trompez pas, j’ai une préférence pour la dénomination anglaise) est un ensemble d’instructions dans une syntaxe qui lui est propre, qui facilite la compilation d’un logiciel. Les ramifications d’un projet, les dépendances et les librairies ou tout simplement l’outillage interne, deviennent inexorablement la rançon d’une complexité après plusieurs décennies d’existence.

Le système le plus répandu est sans conteste Make et son fichier déclaratif Makefile qui contiendra les instructions de compilation. Son principe absolu consiste à transformer un fichier source (le code) en un autre fichier cible (le binaire). Dans un projet minimaliste, le Makefile suivant permet de générer le binaire foo si le code source foo.c ou son en-tête foo.h contiennent des nouveautés.

# ./Makefile
CC=gcc
CFLAGS=-I.

foo: foo.c foo.h
    $(CC) -o foo foo.c

À l’appel de la commande make à la racine du projet, le fichier Makefile sera parcouru pour détecter les cibles du projet et suivre les instructions selon les règles qui y sont renseignées pour construire les fichiers binaires.

Une pratique plus sophistiquée propose de générer ces instructions dans un format compatible avec le système de construction, lorsque celles-ci sont nombreuses, évolutives voire dépendantes d’un contexte ou d’un environnement tel que le système d’exploitation ou l’utilisation d’une option spécifique.

Dans le cas du projet PostgreSQL, c’est la suite GNU Autotools qui a été partiellement retenue pour faciliter la création des binaires sur un ensemble de systèmes compatibles Unix. La génération repose sur les composants Autoconf (fichier configure.ac) et Automake (fichier Makefile.am) pour aboutir au même résultat que la commande make de notre précédent exemple. Dans les faits, seul le premier composant est véritablement employé pour préparer le script configure lors de la compilation de PostgreSQL.

Comme le montre le diagramme ci-dessus, les étapes avant d’obtenir le fichier binaire sont un peu plus nombreuses, et dépendent d’un ensemble de fichiers d’instructions qui deviennent complexes à rédiger sans introduire d’incohérences ou de bogues.

C’est d’ailleurs l’un des constats de la communauté qui, depuis fin 2021, a questionné la possibilité de passer sur un autre système de construction.

Autoconf is showing its age, fewer and fewer contributors know how to wrangle it. Recursive make has a lot of hard to resolve dependency issues and slow incremental rebuilds.

Le principal moteur de la réflexion, Andres Freund, annonçait dans un message sur pgsql-hackers qu’il observait de bien meilleures performances avec une alternative bien plus moderne. Il y énonçait par ailleurs ses arguments pour en finir avec Autoconf :

• « Autoconf et make ne sont plus activement maintenus. Notamment autoconf qui reçoit à peine quelques correctifs mineurs. C’est également des technologies que peu de monde veut utiliser – m4 d’autoconf est effrayant et effraie les personnes qui démarrent bien plus récemment que nous autres, les committers » ;

• « make en mode récursif comme nous l’utilisons n’est pas aussi bien employé que ce qu’il devrait être. L’une des raisons pour laquelle le nettoyage du build est si lent est que nous devons retrouver les dépendances dans un paquet d’endroits. En malgré cela, il m’arrive régulièrement de voir des builds incrémentaux échouer et nécessitant un nouveau rebuild » ;

• « Et nous n’avons pas uniquement un système de build basé sur autoconf et make, il y a surtout le projet de génération MSVC (Microsoft Visual C++) – ce machin que la plupart d’entre nous ne veut pas toucher. Je pense qu’en plus du fait qu’il n’y est pas facile de dérouler tous les tests, ce système est juste tout simplement différent de l’autre, ce qui ne favorise pas l’intérêt des développeurs sous Windows (et indirectement, la qualité de PostgreSQL sur Windows) » ;

• « Le dernier gros problème que je vois avec la situation actuelle est qu’il n’y a aucun bon test d’intégration. Le résultat de make check-world est très majoritairement illisible et impossible à analyser automatiquement. Ce qui impose à la buildfarm de traiter les tests séparément afin que les erreurs puissent être repérées et tracées correctement. Cette approche n’est malheureusement pas adaptée aux processeurs multicœurs et ralentit considérablement l’ensemble des serveurs ».

Meson, une alternative moderne

À l’image des Autotools, Meson est un système qui génère les instructions de compilation. Ce fut le choix qu’a proposé Andres Freund à la communauté après l’avoir analysé aux côtés de CMake et Bazel, deux autres compétiteurs bien connus du monde libre. Meson est écrit en Python et son but premier est de réduire la part d’efforts des développeurs dans la rédaction d’instructions au profit d’une plus grande productivité sur le logiciel en tant que tel.

Le projet Meson s’appuie sur un système de construction bas niveau appelé ninja qui se veut, d’après son auteur Evan Martin, être minimaliste et bien plus performant que make. Les instructions de compilation sont renseignées automatiquement par Meson dans le fichier build.ninja qui sera ensuite parcouru par la commande ninja pour compiler les sources en un fichier binaire.

Pour reprendre mon projet minimaliste foo, le fichier Makefile est remplacé par le fichier meson.build, en y renseignant les méta-données du projet, le point d’entrée du programme et le fichier binaire souhaité.

# ./meson.build
project('foo', 'c')
executable('foo', 'foo.c')

Meson est un jeune projet, dont la première sortie date de 2013. Bien qu’il rougît de son âge face à CMake, il n’en reste pas moins un concurrent qui ne cesse de gagner du terrain depuis la dernière décennie. Parmi les projets qui s’appuient désormais sur Meson, je peux citer de très connus comme : systemd, Gnome et GTK+, QEMU, Xorg et Wayland… De quoi se parer d’une forte communauté d’utilisateurs dans les prochaines années !

Sur la page « Use of Python » du projet, les créateurs de Meson se défendent d’un reproche souvent adressé aux technologies modernes et affirment ne reposer que sur python3 tout en interdisant l’usage de modules externes, en gages de qualité et de compatibilité. Ainsi, le projet se veut accessible pour tous les systèmes d’exploitation, faisait un pied de nez au mastodonte Autotools qui était très couplé au shell Unix dans son implémentation.

La décision pour le projet PostgreSQL de progressivement glisser vers Meson est le fruit de plusieurs mois de réflexion, avec pour ambition notamment de se passer du système MSVC, un ensemble de scripts Perl maison maintenus par une poignée de personnes pour compiler le logiciel sous Windows. En prime, les travaux d’Andres démontrent un gain significatif dans les temps de build, ce qui ne paraît pas surprenant au regard du benchmark entre les deux systèmes sur une architecture ARM.

In any case, using Autotools for a modern C/C++ project in 2021 is like using CVS for source code version control in 2021: there are better tools available and thus it isn’t very interesting to still consider the legacy solutions.

Citation de Georg Sauthoff, The Rise of Meson.

Conclusion

La route empruntée semble la bonne, bien que le chemin soit encore long pour se débarrasser définitivement des résidus historiques d’Autoconf dans le projet PostgreSQL. Lors de la dernière Developer Unconference qui s’est tenue en ligne le 25 mai 2022 lors de l’événement annuel du PgCon, les membres de la communauté ont statué sur les efforts à fournir pour porter ce chantier titanesque.

Avec ce récent patch rattaché à présent à la branche master, la construction des binaires sur la plupart des systèmes d’exploitation est implémentée, avec notamment la compilation de PostgreSQL sur Windows à travers ninja. C’est une première pierre qui est posée pour la prochaine version 16 en cours de développement et l’émergence d’une architecture qui grandira avec d’autres améliorations dans un avenir proche.