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

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…

> 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.

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…).

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.