En examinant les divers scripts de build je constate que deux systèmes redondants cohabitent : cargo-xtask et make.
Y a-t-il une raison pour conserver les deux ? S’il fallait en privilégier un ce serait lequel ?
C’est @sveyret qui a mis en place un Makefile, avant il n’y en avait pas. Les livrables étaient construits par des scripts bash.
Perso je maîtrise pas les Makefile, leur syntaxe est complexe et la doc peu claire, je serais bien incapable de les maintenir.
De plus, les makefile manque de souplesses, je suis pas sûr qu’on puisse tout y faire, par exemple je ne saurais pas vérifier la version de node où forcer la maj du compilateur Rust en fonction de sa version.
C’est peut-être possible, mais ne le sachant pas, je fais avec ce que je sais faire.
C’est pour ça que j’ai fait un script en Rust (xtask) qui me permet de coder tout ce que je veux dans une stack que je maîtrise.
Les 2 systèmes de built sont utilisés dans des scope différents :
- Le makefile est utilisé uniquement dans la CI pour produire les livrables officiels.
- Xtask est utilisé par les utilisateurs de duniter qui souhaitent compiler manuellement duniter (par exemple parce qu’il n’existe pas de livrable officiel pour leur archi/os) et par les testeurs avancés où contributeurs (comme poka, moul et cgeek).
Un avantage important de xtask, c’est qu’il n’ y a rien à installer, ça allège dont l’environnement de développement pour les contributeurs, il suffit juste d’avoir rustc et cargo, dont ils ont déjà besoin pour contribuer au code.
Or je souhaite que l’environnement de dev reste le plus léger possible , qu’il y est le moins de choses à installer pour pouvoir travailler sur Duniter.
D’une part pour faciliter l’onboarding de futurs contributeurs, et d’autres part pour me faciliter la vie à moi car ça me demande moins de chose à réinstaller quand je dois refaire tout un environnement de dev.
Tout faire dans xtask, et migrer la production des livrables officiels dans une commande xtask dédiée, ça simplifierait tout.
D’accord pour simplifier et n’avoir qu’un seul système pour générer tout ce dont on a besoin. Par contre, si on retire le Makefile, il ne faudra pas oublier de porter tout ce qu’il peut faire (cf. en particulier le long commentaire au début du fichier).
Le Makefile est, par exemple, utilisé pour les génération en cross-compilation (sveyret-buildroot/package/duniter/duniter.mk at master · sveyret/sveyret-buildroot · GitHub). Si on le retire, il faudra bien que l’on puisse continuer à générer l’application par Buildroot et (prochainement — je suis en train de travailler dessus) par Yocto.
De toute façon pour le moment j’ai 1000 autres priorités dont les 2 systèmes build vont rester
Je n’ai pas encore de religion sur le sujet. C’est clair que j’ai plus d’affinités pour make, qui est d’une extrême souplesse si on pratique un peu.
De ce que j’ai compris, cargo-xtask existe essentiellement parce que make et bash ne sont pas forcément disponibles sur toutes les plateformes (genre Windows). Mais vu qu’on se limite à Linux, l’argument perd de sa force.
Oui, j’ai l’impression qu’il n’y a plus beaucoup de développeurs pour t’accompagner ! Bon courage, en tous cas ! 
1 Like
Non ce n’est pas la raison pour laquelle je l’ai mis en place. La raison c’est pour répondre à mon besoin qui est :
Fournir une unique commande qui permet de compiler Duniter manuellement en vérifiant automatiquement que l’on a les bonnes versions de Node et de Rust, qui juste marche par défaut (pas truffé d’options complexes), qui ne demande rien à installer, et qui soit dans une techno que je maîtrise déjà pour pouvoir le modifier à ma guise sans perdre de temps.
Je suis pragmatique, je ne fais pas de la technique juste pour la beauté de la technique, mon but est de me concentrer sur ce qui apporte une plus-value aux utilisateurs finaux de la Ğ1.
Donc je n’ai pas envie de passer du temps sur les systèmes de build, dont en fait je ne vais pas les fusionner, si on a 2 systèmes c’est parce qu’il y a deux besoins différents 
Il n’y en a jamais eu beaucoup, on est passé de 1 développeur régulier (cgeek) à … 1 développeur régulier (moi-même).
2 Likes
En vrai on a @tuxmain qui commence à contribuer régulièrement au code de GVA, s’il continue ainsi on pourra dire qu’on a désormais 1,5 contributeurs réguliers au code en lui-même 
2 Likes
@elois j’ai encore une question, mais plus sur cargo lui-même. Pourquoi lorsque je fais :
cargo build --release -p duniter-cli
cargo build --release -p duniter-dbex
cargo build --release -p duniter-cli -p duniter dbex
il va tout recompiler à la troisième étape au lieu de réutiliser les builds précédents ?
qu’entend tu pars « tout recompiler ». Car chez moi « tout recompiler » signifie tout donc les dépendances (car tout inclus tout 
)
Cargo ne recompile que les crates que tu lui demandes de recompiler, qu’est ce qui te fait croire qu’il ne réutilise pas les builds précédents ?
Effectivement, il ne reprend pas tout.
Mais il y a des binaires qu’il régénère alors que ça ne semble pas nécessaire. Par exemple, voici un extrait du contenu de target/release/deps après avoir passé les trois commandes de mon message précédent :
/duniter # ls -lrt target/release/deps/tokio*
-rw-r--r-- 1 root root 64413 May 25 19:20 target/release/deps/tokio-39116c8cb70a52d1.d
-rw-r--r-- 1 root root 64413 May 25 21:16 target/release/deps/tokio-6dcaae4c4971152c.d
On voit que la dépendance tokio a été compilée deux fois : une fois pour le build de duniter-cli et une autre fois pour duniter-dbex. Ou encore :
/duniter # ls -lrt target/release/deps/duniter-*
-rw-r--r-- 1 root root 674 May 25 19:23 target/release/deps/duniter-01e24159beea4de1.d
-rwxr-xr-x 1 root root 6024912 May 25 19:24 target/release/deps/duniter-01e24159beea4de1
-rw-r--r-- 1 root root 674 May 25 21:32 target/release/deps/duniter-6c17ee9732cb153f.d
-rwxr-xr-x 2 root root 6025352 May 25 21:32 target/release/deps/duniter-6c17ee9732cb153f
Le binaire duniter a été recompilé deux fois également, alors qu’il est à jour dès la première commande, normalement.
Je ne comprends pas pourquoi il fait ça.
Parce que ce sont deux binaires différents, chaque binaire à ses propres dépendances, elles ne peuvent pas être mises en commun entre plusieurs binaires. Déjà la source de la dépendance peut être différente (quel git, avec quelle ref, quel path, quel registry, quelle version) mais en plus parce que les features de compilation pour cette dépendance peuvent être différentes.
Chaque binaire a donc son propre arbre de dépendances.
En réalité il s’agit de la crate binaire duniter-cli et elle n’a pas été entièrement recompilée deux fois.
Pour s’en convaincre, il suffit de modifier le code source de duniter-cli puis de lancer deux fois la commande cargo build -p duniter-cli, la 2ème exécution est bien plus rapide :
$ cargo build -p duniter-cli
Compiling duniter-cli v1.8.1 (/home/elois/dev/duniter/nodes/typescript/duniter)
Finished dev [unoptimized + debuginfo] target(s) in 7.87s
$ cargo build -p duniter-cli
Finished dev [unoptimized + debuginfo] target(s) in 0.16s
$
Pourtant si je build en une seule fois en spécifiant -p duniter-cli -p duniter-dbex, il n’y a qu’un seul tokio :
/duniter # ls -lrt target/release/deps/tokio*
-rw-r--r-- 1 root root 64413 May 26 08:50 target/release/deps/tokio-6dcaae4c4971152c.d
Ça ne colle pas avec ton interprétation.
Après là on entre dans des détails techniques sur la manière dont cargo gère les builds intermédiaires qui perso ne m’intéressent pas, d’autant que ça peut changer à chaque maj (toutes les 6 semaines).
Moi ce qui m’intéresse c’est le contrat, c’est comme quand j’utilise une lib, ce qui m’intéresse c’est l’api et la doc de cette lib, de bien lire ce qu’elle me garantit et ce qu’elle ne me garantit pas, je ne vais pas aller creuser sa tambouille interne pour savoir comment elle le fait, sauf si je dois la forker parce qu’elle ne répond pas à mes besoins.
C’est pareil pour cargo, tant que je comprends comment l’utiliser et qu’il répond à mes besoins, je vais pas aller creuser sa tambouille interne. Si toi tu as envie de faire ça, il te faudra aller chercher les infos toi-même
1 Like