Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.
Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.
En Rust, on a pris le meilleur de NPM (la réutilisation du code) sans les défauts (pas de node_modules de 8Go, versions fixées à mettre à jour explicitement donc pas de chaos dûe aux mises à jour auto de colors/faker/leftpad).
A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.
C'est facile de cracher sur npm, c'est moins facile de regarder comment ça marche dans la réalité.
Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.
Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.
Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.
Carrément d'accord mais en même temps, cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
Par exemple, en Ada, il y a Alire qui reprend les mêmes idées mais qui vient concurrencer, par exemple, les repos Debian. Du coup, le mainteneur Debian peut se poser des questions quant à la pertinence de son travail.
A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.
Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique… C'était même plutôt la norme il y a de nombreuses années.
D'ailleurs, même aujourd'hui, rien n'empêche de compiler un code C/C++ en statique et de distribuer le gros binaire.
Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.
Oui, c'est bien ce que je voulais souligner :
langage interprété : beaucoup de dépendances == problématique
langage compilé : beaucoup de dépendances == osef
cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
Sauf que sous Linux, tu n'as pas 2 distributions qui fournissent les mêmes versions de la lib dont tu dépend. Ce qui rend la tâche difficile pour celui qui veut distribuer son logiciel. Plusieurs choix s'offrent à lui :
supporter toutes les distros et chacune des versions de la lib via du code spécifique, des tests de régressions, etc…
supporter une seule version de la lib et donc ne supporter potentiellement que peu de distro Linux
se reposer sur des environnements type flatpak ou docker qui standardise entre plusieurs distro les libs incluses
Je te laisse deviner quel choix est le plus souvent fait.
Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique…
Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.
Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.
Bon, je vais faire fi du ton agressif et/ou hautain.
Par curiosité, j'ai compilé ce code statiquement (hormis pour pthread qui refuse catégoriquement d'être compilé de la sorte) en utilisant la ligne suivante:
c++ -o server server.cpp /usr/lib/x86_64-linux-gnu/libboost_iostreams.a /usr/lib/x86_64-linux-gnu/libboost_thread.a -lpthread
Résultat, l'exécutable pèse 404Ko et la commande ldd me fournit:
L'exécutable, compilé avec les infos de debug, pèse, quant à lui, 3.6Mo mais ne peut pas être compilé entièrement en statique, il semblerait que compiler avec Gtk en statique ne soit pas recommandé.
Le binaire dépend donc finalement de 47 bibliothèques dynamiques.
Et enfin, à titre de comparaison, j'ai créé le Cargo suivant pour compiler le hello world, mentionné en lien plus haut, en Rust:
Tout compile bien en release.
L'exécutable pèse 3.7Mo et dépend de 69 bibliothèques dynamique… Donc finalement, ce n'est pas statique non plus.
Par contre, la compilation en debug produit un exécutable de… 109Mo avec les mêmes 69 libs.
Du coup, là, je suis preneur d'informations pour qu'on m'explique la taille !
Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.
Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.
Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.
Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.
Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.
Dans mon application actuelle voilà mes dépendances :
curl
jansson
mosquitto
sqlite
Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.
A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.
Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).
git is great because linus did it, mercurial is better because he didn't
Justement en tant que dev C/C++ je trouve dommage qu'on doive tout faire à la main.
Ce que tu trouves affligeant est la démonstration de la ré-utilisabilité et c'est un gros manque de C/C++ (qui a des gestionnaires de ce type maintenant mais aucun qui a pris le dessus)
Posté par Zenitram (site web personnel) .
Évalué à -1.
Dernière modification le 14 janvier 2022 à 16:45.
Tu n'as pas à tout faire à la main
Ha? Tu as mis plein de noms sans indiquer comment tu les récupères, Merci, je connais que les libs existent, et c'est n'est pas du tout le sujet.
Le "à la main" concerne comment les installer. Quel équivalent (et donc considéré comme universel par les devs) à npm? C'est la toute la question, à laquelle tu n'as pas répondu (normal, il n'y a pas, je l'ai déjà écrit dans mon commentaire).
Prenons l'exemple de libcurl: apt install libcurl-dev, yum install libcurl-devel, navigateur web ou plein de "packageurs" dont aucun n'a le dessus, pour un seul projet tu n'as déjà pas la même procédure suivant l'OS, ne parlons pas de plusieurs projets.
Tu critiques le Cargo.lock mais tu n'as pas compris à quoi il sert et ce qui manque au C/C++ par rapport à d'autres langages. Il manque clairement un npm au C/C++, il y a des tentatives mais aucune de référence comme pip ou npm pour les autres langages.
Donc : tu ne démontres absolument pas "Tu n'as pas à tout faire à la main" (tu démontres plutôt le contraire en fait, en tapant à côté du problème), c'est affligeant pour reprendre un mot utilisé ici.
Le cargo.lock a peu d'intérêt car il est généré.
Le fichier intéressant est le cargo.toml qui liste les dépencences, 390 lignes.
Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers boostrap, 1102 lignes, configure.ac, 750 lignes et Makefile, 215 lignes, init.cfg, 764 lignes qui semblent nécessaires à la compilation de la version GNU.
Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers boostrap, 1102 lignes, configure.ac, 750 lignes et Makefile, 215 lignes, init.cfg, 764 lignes qui semblent nécessaires à la compilation de la version GNU.
La différence, c'est que ça, c'est déjà du code, pas des dépendances.
En plus, c'est du code de build donc si tu veux comparer, il faudrait aller regarder comment est codé le cargo build.
Au final, tu compares 3000 lignes de code avec un listing de 390 dépendances qui, elles,contiennent aussi beaucoup de code.
Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.
Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
Oui, pour favoriser l'adoption dans certains contextes (embarqué, par exemple) :
[The MIT Licence] potentially makes it more attractive for use in places where software licensed with GPLv3 is not adopted due to its restrictions on Tivoization among other things
Le lien date de juillet 2021. On peut le mettre en lien avec ce billet de mars 2021 d'une personne de chez Mozilla qui l'a empaqueté pour Debian (il avait déjà fait un exercice similaire avec CLang) puis utilisé au quotidien en conditions réelles. https://sylvestre.ledru.info/blog/2021/03/09/debian-running-on-rust-coreutils
# Cargo.lock affligeant
Posté par David Demelier (site web personnel) . Évalué à 8.
Quand je vois le Cargo.lock du projet je suis content de toujours développer en C et C++ et ne pas faire parti du nouvel npm.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par David Delassus (site web personnel) . Évalué à 9.
Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.
Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.
En Rust, on a pris le meilleur de NPM (la réutilisation du code) sans les défauts (pas de node_modules de 8Go, versions fixées à mettre à jour explicitement donc pas de chaos dûe aux mises à jour auto de colors/faker/leftpad).
A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.
C'est facile de cracher sur npm, c'est moins facile de regarder comment ça marche dans la réalité.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Cargo.lock affligeant
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.
Carrément d'accord mais en même temps, cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
Par exemple, en Ada, il y a Alire qui reprend les mêmes idées mais qui vient concurrencer, par exemple, les repos Debian. Du coup, le mainteneur Debian peut se poser des questions quant à la pertinence de son travail.
Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique… C'était même plutôt la norme il y a de nombreuses années.
D'ailleurs, même aujourd'hui, rien n'empêche de compiler un code C/C++ en statique et de distribuer le gros binaire.
[^] # Re: Cargo.lock affligeant
Posté par David Delassus (site web personnel) . Évalué à 0.
Oui, c'est bien ce que je voulais souligner :
Sauf que sous Linux, tu n'as pas 2 distributions qui fournissent les mêmes versions de la lib dont tu dépend. Ce qui rend la tâche difficile pour celui qui veut distribuer son logiciel. Plusieurs choix s'offrent à lui :
Je te laisse deviner quel choix est le plus souvent fait.
Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Cargo.lock affligeant
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
Bon, je vais faire fi du ton agressif et/ou hautain.
Par curiosité, j'ai compilé ce code statiquement (hormis pour pthread qui refuse catégoriquement d'être compilé de la sorte) en utilisant la ligne suivante:
Résultat, l'exécutable pèse 404Ko et la commande ldd me fournit:
On voit donc bien que Boost est compilé statiquement.
Le poids cumulé des deux archives est de 968Ko, le linker a donc bien fait son travail.
Du coup, comme tu listais aussi Gtk, j'ai fait un petit code en GtkAda qui match le code le plus simple du site gtk-rs.
L'exécutable, compilé avec les infos de debug, pèse, quant à lui, 3.6Mo mais ne peut pas être compilé entièrement en statique, il semblerait que compiler avec Gtk en statique ne soit pas recommandé.
Le binaire dépend donc finalement de 47 bibliothèques dynamiques.
Et enfin, à titre de comparaison, j'ai créé le Cargo suivant pour compiler le hello world, mentionné en lien plus haut, en Rust:
Tout compile bien en release.
L'exécutable pèse 3.7Mo et dépend de 69 bibliothèques dynamique… Donc finalement, ce n'est pas statique non plus.
Par contre, la compilation en debug produit un exécutable de… 109Mo avec les mêmes 69 libs.
Du coup, là, je suis preneur d'informations pour qu'on m'explique la taille !
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . Évalué à 10.
Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.
Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.
Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.
Dans mon application actuelle voilà mes dépendances :
Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.
Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par Zenitram (site web personnel) . Évalué à 10.
Justement en tant que dev C/C++ je trouve dommage qu'on doive tout faire à la main.
Ce que tu trouves affligeant est la démonstration de la ré-utilisabilité et c'est un gros manque de C/C++ (qui a des gestionnaires de ce type maintenant mais aucun qui a pris le dessus)
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . Évalué à 1.
Tu n'as pas à tout faire à la main
D'ailleurs le plus simple c'est de chercher dans les projets “awesome”.
Pour C, pour C++.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 14 janvier 2022 à 16:45.
Ha? Tu as mis plein de noms sans indiquer comment tu les récupères, Merci, je connais que les libs existent, et c'est n'est pas du tout le sujet.
Le "à la main" concerne comment les installer. Quel équivalent (et donc considéré comme universel par les devs) à npm? C'est la toute la question, à laquelle tu n'as pas répondu (normal, il n'y a pas, je l'ai déjà écrit dans mon commentaire).
Prenons l'exemple de libcurl:
apt install libcurl-dev
,yum install libcurl-devel
, navigateur web ou plein de "packageurs" dont aucun n'a le dessus, pour un seul projet tu n'as déjà pas la même procédure suivant l'OS, ne parlons pas de plusieurs projets.Tu critiques le Cargo.lock mais tu n'as pas compris à quoi il sert et ce qui manque au C/C++ par rapport à d'autres langages. Il manque clairement un npm au C/C++, il y a des tentatives mais aucune de référence comme pip ou npm pour les autres langages.
Donc : tu ne démontres absolument pas "Tu n'as pas à tout faire à la main" (tu démontres plutôt le contraire en fait, en tapant à côté du problème), c'est affligeant pour reprendre un mot utilisé ici.
[^] # Re: Cargo.lock affligeant
Posté par YBoy360 (site web personnel) . Évalué à 3.
Les modules du C++ 2020 ne permettent pas justement de rapatrier des binaires "portables" de façon agnostique ?
Pour gérer les dépendances, c'eût été pratique …
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . Évalué à 4.
Non les modules C++ sont juste une alternative saine aux
#include
.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par Tonton Th (Mastodon) . Évalué à 4.
Mais mais mais, il n'y a que du code qui sort de chez Microsoft !
[^] # Re: Cargo.lock affligeant
Posté par steph1978 . Évalué à 2.
Le
cargo.lock
a peu d'intérêt car il est généré.Le fichier intéressant est le
cargo.toml
qui liste les dépencences, 390 lignes.Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers
boostrap
, 1102 lignes,configure.ac
, 750 lignes et Makefile, 215 lignes,init.cfg
, 764 lignes qui semblent nécessaires à la compilation de la version GNU.[^] # Re: Cargo.lock affligeant
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
La différence, c'est que ça, c'est déjà du code, pas des dépendances.
En plus, c'est du code de build donc si tu veux comparer, il faudrait aller regarder comment est codé le cargo build.
Au final, tu compares 3000 lignes de code avec un listing de 390 dépendances qui, elles,contiennent aussi beaucoup de code.
Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.
[^] # Re: Cargo.lock affligeant
Posté par freem . Évalué à 4.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
# Changement de licence au passage
Posté par cg . Évalué à 3.
Fait notable, la licence n'est pas la GPL mais la MIT. Au moins, c'est clairement indiqué et assumé.
(Perso je trouve ça dommage, mais inutile de démarrer un énième débat sur les licences, on n'est pas dredi non plus).
[^] # Re: Changement de licence au passage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 14 janvier 2022 à 19:23.
C'est dans l'espoir de susciter plus d'adoption ou est-ce juste un repère d'anti-libres ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Changement de licence au passage
Posté par cg . Évalué à 3.
Oui, pour favoriser l'adoption dans certains contextes (embarqué, par exemple) :
[^] # Re: Changement de licence au passage
Posté par Christophe . Évalué à 4.
On n'est pas dredi ? Tu es sûr ? :)
# retours intéressants de Sylvestre L.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Le lien date de juillet 2021. On peut le mettre en lien avec ce billet de mars 2021 d'une personne de chez Mozilla qui l'a empaqueté pour Debian (il avait déjà fait un exercice similaire avec CLang) puis utilisé au quotidien en conditions réelles.
https://sylvestre.ledru.info/blog/2021/03/09/debian-running-on-rust-coreutils
L'auteur est revenu ce mois-ci avec un billet pour faire le point sur l'avancement, suite à la sortie de la version coreutils 0.0.12 : les choses avancent mais la route est longue…
https://linuxfr.org/users/antistress/liens/sylvestre-ledru-and-other-developers-have-been-working-on-a-rust-based-coreutils-phoronix#comment-1881821
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.