Une défense des autotools

Je sais que beaucoup de gens aiment bien dire pis que pendre des autootools, mais j’aimerais quand même les défendre un peu, à la fois du point de vue de l’utilisateur (ie, celui qui veut compiler et installer un programme utilisant les autotools) et du point de vue du développeur (celui qui utilise les autotools pour gérer son projet).

Du point de vue de l’utilisateur, d’abord un peu de contexte. J’utilise Slackware, qui comme vous le savez peut-être est fournie avec assez peu de logiciels, de sorte qu’il m’arrive fréquemment de compiler moi-même les programmes que j’utilise (certainement plus souvent qu’un utilisateur de Debian ou Fedora par exemple). À titre indicatif, sur les 1534 paquets installés présentement sur mon système, 387 (25%) sont étrangers à la distribution et ont été compilés par mes soins. Une conséquence de ça, c’est que je suis pas mal confronté aux systèmes de build (non pas que ça me fasse grand plaisir, mais quand on choisit Slackware on sait à quoi s’attendre).

Encore un peu de contexte, avec quelques chiffres : sur les 387 paquets que j’ai construit moi-même et que j’utilise actuellement (je ne compte pas les paquets que j’ai construit par le passé mais que je n’utilise plus), j’enlève 149 paquets pour des modules Python qui ne sont pas vraiment pertinents ici (ils se construisent tous de la même manière, python setup.py build — et bon sang comme c’est agréable). Reste 238 paquets non-Python qui se répartissent ainsi :

• 173 utilisant les autotools (73%) ;
• 22 utilisant un « simple » (ou moins simple) Makefile (9%) ;
• 19 utilisant CMake (8%) ;
• 9 utilisant Waf (4%) ;
• 9 utilisant QMake (4%) ;
• 3 utilisant un système maison (1%) ;
• 2 utilisant Meson (1%) ;
• 1 utilisant Ant (< 1%).

Et bien, pour moi, le bilan est sans appel : je préfère largement construire un paquet pour un projet utilisant les autotools. Presque tous les autres systèmes m’ont posé des casses-têtes que je n’ai jamais eu avec les autotools qui sont pourtant beaucoup plus fréquents.

Pêle-mêle, quelques trucs qui m’irritent presque chaque fois que je dois compiler un projet sans les autotools :

• Pas toujours d’option standard pour indiquer où placer les bibliothèques. J’ai toujours besoin d’une option de ce genre, parce que Slackware a choisi, pour sa version 64 bits, d’installer les bibliothèques dans /usr/lib64 au lieu de /usr/lib. Oui, c’est un choix qui va à l’encontre de la plupart des autres distributions, mais il n’empêche : le système de build est supposé permettre de s’adapter au système cible. S’il ne le permet pas, c’est un système de build de merde, dont je maudis les auteurs sur cinq générations.

Mention très défavorable à CMake, qui est quand même là depuis suffisamment longtemps pour qu’on puisse se dire qu’une telle option devrait être disponible en standard, mais non : avec CMake, chaque projet fait sa propre sauce. Parfois il y a une option LIB_SUFFIX, parfois une option INSTALL_LIB_DIR, parfois une option WANT_LIB64, parfois une option MULTIARCH_SUFFIX — j’adore parcourir les CMakeLists.txt à la recherche de la bonne option, c’est ma joie —, et parfois... il n’y a pas d’option : le chemin d’installation des bibliothèques est codé en dur et il faut aller le modifier soi-même dans le CMakeLists.

• Pas toujours d’option standard pour indiquer où placer les pages de manuel ou d’info. Idem que ci-dessus. Avec les autools, c’est --mandir et --infodir. Avec CMake, parfois c’est MANDIR, le plus souvent c’est rien du tout, encore une fois il faut changer le chemin codé en dur dans le CMakeLists (ou aller déplacer les pages de manuel dans le bon dossier après installation).

• Plus généralement, le fait que tous ces projets ne sont pas fichus de s’arranger pour avoir une interface raisonnablement commune. Pensez ce que vous voulez des autotools, mais ils sont là depuis plus de vingt ans et les développeurs y sont habitués. Si vous voulez coder le nouveau build system du futur, au moins essayez de coller autant que possible à la syntaxe du classique configure (un bon point à Waf et Meson sur ce point — CMake, va te jeter dans les flammes de la Montagne du Destin où tu as été forgé, merci).

• Le simple fait de devoir installer yet-another-build-system juste pour pouvoir compiler un logiciel. Les autotools ont ceci de pratique qu’ils ne doivent être installés que sur la machine du développeur. Côté utilisateur, un shell (même pas besoin que ce soit GNU Bash) et un make (même pas besoin que ce soit GNU Make) suffisent. Mention spéciale aux projets qui ne se compilent qu’avec la dernière version de leur build-system, celle qui est sortie avant-hier.

Du point de vue du développeur maintenant : les autotools ne sont certes pas parfait (notamment, ils sont lents, c’est indéniable), mais il y a quand même quelques petites (ou pas si petites) choses que j’apprécie, comme :

• le support de la compilation croisée, y compris vers Windows (--build=x86_64-slackware-linux --host=i686-mingw32) ;
• make distcheck, pour non seulement générer une tarball mais vérifier automatiquement qu’elle est complète et autosuffisante ;
• le support automatique de toutes les options qu’on attend d’un système de build conforme aux GNU Coding Standards (--prefix, --libdir, --mandir, plus généralement tous les --machinsdir, --disable-static, --program-prefix, etc.) ;
• la prise en charge de gettext (alors là, je suis d’accord, c’est géré de façon très moche — mais au moins c’est géré, ce qui n’est pas le cas avec tous les autres systèmes...).

Les autotools ont leur défaut, certes. Mais demandez-vous aussi pourquoi ils sont encore massivement utilisés.

Pour ma part, franchement, je n’ai vu passer aucun système de build que je puisse considérer comme un successeur crédible aux autotools (non, CMake n’est pas un successeur crédible, voir ci-dessus), à part Meson récemment qui semble prometteur.