Comments on Clopen source : de la difficulté croissante de compiler des programmes

Numbra (2026-02-02T12:20:25Z)

Globalement d'accord avec tout. Pour Gentoo (qui est un cas à part), je ne suis pas sûr de comprendre ce que tu veux dire par

> Mais ce n'est pas la compilation au sens dont je parle ici : je parle de recompiler la version upstream, celle qui est publiée par les auteurs du programme, pas un package source créé par les mainteneurs de la distribution

De fait, un "paquet" Gentoo, c'est un script bash qui explique où récupèrer les sources, et contient le reste des instructions pour compiler lesdites sources (le "script bash" en question n'en est plus vraiment un étant donné le nombre de fonctions prédéfinies pour configurer/compiler/installer/etc les sources, on est assez loin du pur Bash, mais c'est réellement un DSL en Bash). Les scripts en question sont appelés "ebuild".

En particulier:
- La compilation proprement dite est faite offline, le seul moment où on a besoin du réseau est celui où on télécharge les sources (c'est d'ailleurs un merdier sans nom pour faire fonctionner certains gestionnaire de paquets annexes, comme (p)npm, qui supposent un accès à Internet pendant longtemps dans la chaine de compil' et dont les options pour résoudre et télécharger les dépendances sont imbittables pour qui est néophyte dans l'""écosystème"" Javascript).
- Un certain nombre de chemins peuvent être définis via des variables d'environnement. C'est, en gros, l'astuce utilisée derrière Crossdev (outil qui facilite l'installation de chaines de cross-compilation) et Gentoo Prefix (qui permet d'utiliser Portage, le gestionnaire de paquets, sur n'importe quel distribution, et dans des dossiers personnels de l'utilisateur -- en particulier, /pas/ dans des dossiers "système" souvent lock par le sysadmin de l'école/l'entreprise/etc).
- Le gestionnaire de paquets (Portage, donc) tente tant bien que mal de subsumer les gestionnaires de paquets concurrents de tous les langages de programmation du monde (Cargo en Rust, Cabal en Haskell, Dune pour OCaml, etc etc). C'est évidemment complètement con d'avoir un gestionnaire différent par langage (qu'est-ce qu'on fait si on programme dans un langage X a des dépendances qui sont écrites dans un langage Y ?! Et c'est seulement un des problèmes …), mais Portage tente d'émuler un peu tous les autres, en récupérant les sources des paquets et en recompilant localement. Concrètement, beaucoup d'ebuild sont générés automatiquement depuis les gestionnaires annexes, en espérant que les dépendances, versions, options … etc soient correctement renseignées.
- Un ebuild donné va chercher les sources d'une version donnée, mais pour un certain nombre de paquets, il y a des ebuilds (dans la distribution par défaut -- n'importe qui peut en écrire un autrement, de toute façon) qui pointent vers "le dernier commit sur la branche X de tel dépot disponible à telle adresse". Ils sont souvent légèrement différent de ceux pour les versions "stables", mais pas nécessairement, et c'est assez trivial d'en écrire un s'il n'existe pas déjà.

Bon, c'est vrai que c'est un niveau d'indirection supplémentaire : on compile localement, de façon très personnalisable … mais grâce à des scripts possiblement obscurs (ebuilds) qui sont (pour les programmes complexes) globalement inécrivables par un utilisateur moyen "from scratch". En contrepartie, pour des petits programmes pour lesquels la compilation est une invocation claire & simple du genre "./configure && mkdir build && make && … && make install", on peut écrire un ebuild en 4 lignes qui va s'intégrer au reste du package manager, qui trackera les dépendances, ira les installer, etc etc.

Ruxor (2026-01-29T09:15:04Z)

@jeanas:

D'abord, un point central de mon reproche est la perte de standardisation dans le fait que les outils de compilation se fragmentent selon le langage alors que n'importe qui a le droit de vouloir compiler des choses écrites dans n'importe quel langage dont il n'est pas familier. Donc tu devrais éviter de parler de cargo vu que tu es, je crois, familier de Rust. Dis-moi plutôt si tu trouves facile de compiler, disons, un projet en Java ou en C# ou en Go, parce que c'est bien ça l'enjeu : combien de temps tu perds à découvrir comment ce langage fait sa sauce. Et si tu me dis que tu n'as pas de temps à perdre avec ça, c'est PRÉCISÉMENT mon point.

(Le concept même d'avoir des outils de build ou d'organisation spécifiques à un langage est quand même hallucinant de stupidité, quand on y pense. Un compilateur prend des entrées pour produire des sorties : un outil de build devrait pouvoir s'adapter à n'importe quel programme qui fait ça ; make a plein de défauts, mais au moins il peut fonctionner avec n'importe quel langage. C'est comme si Springer prétendait me dicter comment ranger les livre Springer sur ma bibliothèque avec un Springer book manager propriétaire.)

Ensuite, oui, je me doute bien que l'outil choisi par les devs du projet est commode pour les choses que cherchent à faire les devs du projet. Probablement même pour reproduire les binaires exacts qu'ils distribuent (vu que je suppose que le processus est automatisé), mais justement, ce n'est pas ce qui m'intéresse, parce que, si c'est ça pour faire ça, autant les récupérer directement compilés.

Le genre de choses que je demande, moi, c'est plutôt :

⁃ Installer chaque package non fourni par la distrib dans son propre /opt/trucmuche-0.42 parce que c'est comme ça que j'ai choisi d'organiser ma machine (mon /usr/local est essentiellement vide : tout ce que je compile moi-même est dans un /opt/quelquechose), donc s'il y a des dépendances je veux que chacune aille dans le répertoire correspondant et n'écrive rien en-dehors de ce répertoire. Avec les GNU autotools, c'est l'option --prefix qui fait ça, et pour beaucoup d'outils je ne trouve rien d'équivalent, ou alors c'est super caché (par exemple il faut positionner plein de variables d'environnement différentes).

(Le point crucial, en tout cas, c'est que contrairement à une distrib qui peut évidemment organiser les fichiers comme elle l'entend, un système de compilation à partir de la source doit permettre n'importe quel choix derrière : tout mettre dans /usr/local, ou tout mettre dans $HOME, ou mettre dans des /opt/bidule tous séparés, ou encore n'importe quoi d'autre.)

Bon, je crois comprendre que Rust n'a pas encore de mécanisme de bibliothèques partagées, donc la question ne se pose pas trop pour lui (de toute façon tout va être mis dans un binaire statique énorme), mais quand ça va arriver, j'ai vraiment peur de ce que ça donnera de ce point de vue-là.

⁃ Lister toutes les options pertinentes pour la compilation (l'équivalent du --help de configure) avec des explications sur ce qu'elles font. Les projets font de moins en moins l'effort de documenter tout ça, précisément parce qu'ils supposent que personne ne va les compiler.

⁃ Séparer l'étape de récupération des sources et celle de compilation proprement dite, parce que, oui, ça m'arrive de compiler dans le train. Je veux pouvoir récupérer un package de source avec toutes les sources du projet, ou un README qui me dit les sources de quelles dépendances je dois récupérer avant de commencer. Ensuite, la compilation doit pouvoir se faire sans réseau.

⁃ Décider combien de cœurs de CPU je dédie à la compilation (ma machine de bureau est un bi-Xeon, chaque package ayant 8 cœurs hyperthreadés, donc il faut lancer qqpart entre 1 et 32 jobs parallèles de compilation : je ne demande pas que ce soit décidé automatiquement, je veux savoir comment je précise). S'il y a maintenant 42 outils qui remplacent make, je n'ai pas envie d'apprendre 42 options différentes, ça doit être documenté dans un README.

⁃ Plus avancé : quels paramètres passer pour cross-compiler (parce que j'ai aussi des machines ARM donc je dois parfois utiliser la cible aarch64-linux-gnu alors que je compile sur x86_64-linux-gnu).

⁃ Avoir un peu d'explications sur l'organisation de l'arbre de compilation, au moins savoir où sont les sources, où arrivent les binaires, etc. Et aussi comment l'espace est pris.

À ce propos, même si c'est un problème différent, la compilation de deno a occupé, finalement, 71Go d'espace, ce qui est juste totalement hallucinant : même une compilation Android complète n'en prend pas autant, il me semble. Pourquoi est-ce que j'ai dans chacun de target/release/deps/ et target/debug/deps/ pas moins de trois binaires énormes avec un nom en deno-<truc hexa> (je veux bien admettre qu'il y ait une version release et une version debug différentes, mais pourquoi il en a fait trois de chaque) ?

Tout ça est peut-être clair pour quiconque connaît l'outil, mais mon objection est, justement, que la multiplicité des outils fait que ce n'est plus raisonnable de demander qu'on les connaisse. Donc ce que je demande avant tout est une doc qui répond rapidement aux questions telles que celles que je liste ci-dessus, pour les gens qui ne connaissent pas les outils. Je ne demande pas qu'ils en changent, juste qu'ils documentent comment faire les choses !

Par ailleurs, ton reproche de manque de compatibilité des systèmes basés sur GNU est vraiment injuste : j'ai compilé des outils GNU sur un Unix v7 tournant sur un émulateur de PDP-11 ! La diversité des systèmes auxquels on a affaire maintenant est minuscule par rapport à il y a 25–30 ans (et la blague des Solaris sur lesquels le sh de /usr/bin ne se comporte pas pareil que celui de /usr/ccs/bin ni que celui de /usr/xpg4/bin ni que celui de /usr/ucb ce n'était pas très drôle). Ce n'est pas quelque chose que je regrette, mais si tu dis que tu observes des problèmes de compatibilité malgré cette limitation incroyable de la difficulté, ben c'est bien le signe que les dévs ne font plus d'efforts pour qu'on puisse compiler leurs projets, et c'est exactement ce dont je me plains.

Fred le marin (2026-01-28T18:53:24Z)

Un monde à (tenter de) sauver ?

Ma mémoire vive me rappelle que les "makefiles" avaient (ont) une syntaxe particulièrement sobre mais assez peu intuitive : il faut connaître, comme en Python, la placement des tabulations et autres règles d'écriture.
Après il y a eu Ant et puis Maven, dans mon cas pour du Java.
A présent, apparemment, Cargo de nuit…

jeanas (2026-01-28T17:23:06Z)

> Et il me semble que plus le temps passe, plus la compilation devient difficile.

Mon expérience personnelle n'est vraiment, mais alors vraiment pas du tout la même. Par exemple, quand tu m'as demandé de l'aide pour compiler Deno, j'ai testé « cargo install deno », ça a donné une erreur parce qu'il me manquait cmake, re-testé, manquait clang, re-testé, j'avais oublié le --locked, re-testé, ça a fonctionné. Quasiment tout le temps que j'y ai passé a été passé à attendre pendant que le machin compilait, pas à chercher quoi faire. D'accord, il faut savoir que la commande s'appelle « cargo install --locked », et oui, ça m'énerve que cargo écrive dans mon $HOME. (Mais je rappelle que ce sont seulement des sources, pas des binaires, donc ça ne pose pas de problème de reproductibilité.) En contrepartie,

‣ On parle quand même d'un projet de ≈ 700 000 lignes de code. Honnêtement, il y a 15 ans, quelle était l'envergure maximale d'un projet que tu pouvais compiler en réussissant à la quatrième commande ?

‣ Je peux trivialement changer la version que je compile, y compris à un commit Git arbitraire d'un fork, ce qui me semble quand même le plus fondamental en termes de liberté. Avec autotools, soit je me limite à une version pour laquelle les mainteneurs ont créé une tarball avec le script configure pré-généré, soit j'ai une étape de plus pour trouver avec quel autre script il est généré et ce que demande cet autre script. Super pour la reproductibilité, au passage, ces scripts générés et mis dans les releases.

‣ Si veux changer la version d'une dépendance, voire lui appliquer un patch, c'est aussi très facile. Je n'ai pas à compiler séparément cette dépendance. S'il y a plusieurs dépendances intermédiaires entre le produit final et cette dépendance, je n'ai pas non plus à m'en occuper.

‣ Ces vieux build systems sont assez invasifs sur le système, en fait, vu qu'ils vont souvent chercher des fichiers pkg-config dans /usr/ et des commandes dans $PATH, et bon courage pour les pointer vers autre chose (et à nouveau, super pour la reproductibilité). D'ailleurs souvent ils ne sont testés qu'avec Bash et GNU coreutils.

Je ne trouve franchement pas qu'on ait perdu au change.

Yvan (2026-01-28T16:00:23Z)

Il n'existe pas des distributions où l'on peut tout compiler avec bazel ou équivalent ?

Dans mon entreprise, on intègre toutes nos dépendances dans le mono repo et on compile littéralement tout avec bazel (du C++, du Rust, du Python etc etc…).

patrick_g (2026-01-28T15:43:04Z)

Le repository AUR d'Arch Linux est bien foutu pour ça.
La grande majorité des logiciels d'Arch sont sous forme de paquets binaires mais quand un truc manque on peut se servir d'AUR pour télécharger les sources de ce logiciel manquant et compiler dans la foulée.
Par exemple si je veux installer sirikali (un front-end graphique pour faire du chiffrement de disque).

git clone https://aur.archlinux.org/sirikali.git

ça va m'installer un script PKGBUILD que je peux lire et modifier comme je veux.
Voir par exemple celui de sirikali ici :
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=sirikali

Ensuite je n'ai plus qu'à faire un make pour exécuter les instructions du PKGBUILD (download du source et compilation).
C'est un bon compromis je trouve.