Petit journal bookmark pour vous annoncer une nouvelle sur laquelle je suis tombé. Le projet Debian a été recompilé avec Clang/LLVM (un compilateur libre, concurrent de GCC). Les points intéressants soulevés (autre que faire plaisir aux fanboys Clang) sont que ça permet une meilleure qualité du code en utilisant deux compilateurs différents (qui ne soulèvent pas les mêmes problèmes et que ça permet de montrer que Clang est viable en tant que compilateur.
Sur les 15658 paquets, 1381 (8.8 %) n'ont pas pu être recompilés. Le récapitulatif des erreurs est disponible sur la page Clang de Debian.
# Ca fait du bien...
Posté par Zenitram (site web personnel) . Évalué à 10.
Avec un peu de chance, on verra enfin des codeurs "intégristes" ne pas rejeter des patchs pour corriger le mauvais code C/C++ parce que "ça fonctionne très bien avec GCC qui est ma norme, et c'est plus optimal comme ça". Vive le code standard, même si du coup ça permet d'être compilé par les OS du mal (c'est ça les standards…)
Très beau projet, ça fait du bien une remise en cause du tout GCC.
[^] # Re: Ca fait du bien...
Posté par claudex . Évalué à 5.
Je ne vois pas pourquoi ces codeurs accepterais ces patchs suite à ça. Par contre, il y a des chances qu'ils soient disponible dans les paquets Debian.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ca fait du bien...
Posté par Zenitram (site web personnel) . Évalué à 2.
Je pense que corriger pour un autre compilo libre (même si la licence non copyleft pue ;-) ) est un argument qui les touchera plus que de dire que c'est pour que Visual C++ puisse compile un code standard. Argumenter avec des arguments qui touche le codeur (comme lui dire que le libre ne peut pas utiliser son code sans ce patch donc qu'il ne joue pas le jeu de la "communauté") marche souvent mieux ;-).
Et au pire on aura le paquet orig de Debian (donc assez maintenu, même si ce n'est aps toujours à jour), effectivement, ce sera un pis-aller.
[^] # Re: Ca fait du bien...
Posté par moi1392 . Évalué à 7.
Perso ce qui me touche le plus, c'est que mon code soit standard ou pas.
Si on me montre du code à moi qui compile sous g++ mais pas sous vs2048 mais qui n'est pas du c++ standard, je n'ai pas de soucis à le corriger, par contre, si on me propose un patch dans le même contexte pour passer d'une code standard à un code non standard c++, là, ça m'emmerde vraiment.
Malheureusement, c'est le plus souvent le second cas. Pire, au boulot, les "intégristes" ralent quand je corrige leur code non standard qui ne compile que sous vs8023, même si je leur dit/explique/décrit clairement et compréhensiblement (pour un développeur) pourquoi ce qu'ils ont écrit est faux et ne devrait pas pouvoir être compilé, ou n'a pas un comportement normal.
Exemple classique : l'appel à un membre (méthode ou attribut) hérité dans un template qui dérive de son argument de template non préfixé par "this->"
Et ça, c'est seulement pour un exemple de vrai erreur du compilo, y'a tout le code non standard qui va avec, comme pour le nommage des enum, les >> sans espaces pour les templates de templates (remarque que ces 2 exemples sont maintenant dans c++11), la surqualification dans les déclarations de membres de classes, l'opérateur ternaire ?: qui se permet "d'optimiser" en n'appelant qu'une seule fois une fonction si tu la places 2 fois dans l'expression (qu'est-ce que j'ai galéré pour comprendre ce bug à la con…) j'en passe et des meilleurs…
[^] # Re: Ca fait du bien...
Posté par ckyl . Évalué à 2.
Et elle est où votre intégration continue qui va échouer jusqu'à temps que le code soit correct ?
Si dans le cahier des charges y'a marqué que le code n'est pas ciblé que sur un compilo précis alors tu fais passer tes builds avec plusieurs implémentations de compilo et voilà.
[^] # Re: Ca fait du bien...
Posté par moi1392 . Évalué à 2. Dernière modification le 06 mars 2012 à 13:36.
Elle est là depuis quelques temps :) (jenkins)
Du coup j'en vois effectivement moins. Mais comme je compile avec du g++ 4.6 alors que les builds officiels utilisent un 4.1 (redhat 5), je me tape des soucis de temps à autre tout de même.
Un autre problème est qu'elle ne compile que les quelques branches principales, donc elle n'est pas utile dans certains de mes développement.
[^] # Re: Ca fait du bien...
Posté par ckyl . Évalué à 2.
Faut pas hésiter a être agressif sur les environnements de build. Ca coute rien de vérifier sur bien plus de cibles que ce qui est supporté par la release et permet de chopper les problèmes en avance lors du dev plutôt que deux ans après quand tu changes d'environnement cible et que tout casse en même temps et que ca devient indébuggable. Au pire même si tu fixes pas tout pour certains cas spécifiques, tu as déjà identifier depuis longtemps les parties de code qui vont poser problème.
Pour ce qui est des branches. C'est l'ennemie de l'intégration continue. Il faut soit adopter des cycles de branche très court et intégrer agressivement dans le trunk (version agile, tes branches c'est 2 à 15 jours de boulot max, quand tu merges tout doit être vert). Soit avoir très peu de branches et des cycles très longs avec un build branché sur chaque branche. Le cout de QA par branche n'est pas nul, donc souvent opter pour la première version est une bonne idée.
Mais il y des solutions pour forcer en douceur les gens à faire le travail.
[^] # Re: Ca fait du bien...
Posté par moi1392 . Évalué à 1.
Le problème, c'est les moyens : temps de compilation et machines dispos.
Mais on s'améliore, doucement mais sûrement :)
[^] # Re: Ca fait du bien...
Posté par Zenitram (site web personnel) . Évalué à 7.
Il y a de tout, je me suis déjà pris un "won't fix" sur une ré-écriture standard c++ (crade peut-être, mais standard) d'une fonction compilable uniquement par gcc (car utilisant des extensions gcc).
Ce n'est pas parce qu'il faut se battre contre ceux faisant du code compilable que sur msvc que ça nous permet de faire la même chose, ce n'est pas mieux, certains l'oublient…
Dans le même style, il y a ceux qui n'ont rien à foutre si leur fichier .h C ne compile pas par un compilateur C++ standard (ben oui, on peut utiliser du C en C++ si quelques mots clé C++ ne sont pas pris comme nom de variable), on a de tout en intégriste :), et on ne peut pas faire grand chose que de maintenir un .diff :(.
[^] # Re: Ca fait du bien...
Posté par moi1392 . Évalué à 4.
là effectivement, c'est dommage :/ (je trouve même ça très con comme comportement)
[^] # Re: Ca fait du bien...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 7.
FreeBSD fait la même chose depuis un certain temps déjà, et il semble que les patches sont plutôt bien acceptés par les projets upstreams.
# Impressionné
Posté par chimrod (site web personnel) . Évalué à 6.
J'ai l'impression que Debian devient un terrain de jeu d'expérimentateurs en tous genre (BSD, llvm…).
Non pas pour intégrer de nouvelles technologies (pulseaudio, Wayland), où la distribution suit le mouvement plus qu'elle ne l'impose, mais davantage comme données d'expérimentation.
Pourquoi Debian et pas une autre distribution ? (Essayons d'éviter le troll) La distribution n'est pas connue pour être orientée compilation (par opposition à LFS, gentoo…)
Il y a un temps, on disait que l'avantage de Debian était d'avoir une base d'utilisateur importante pour remonter les bugs, ça pourrait être une piste. Quelqu'un en voit d'autres ?
[^] # Re: Impressionné
Posté par Zenitram (site web personnel) . Évalué à 8.
De ma vision assez lointaine certes, j'ai l'impression que l'équipe Debian s'est bottée le cul ces derniers temps pour fournir les outils nécessaires à des compilations automatiques de masse avec 36 options de partout (y compris sur le coeur de l'OS), ce que ne font pas les autres. Ils étaient en retard (cf multi-arch), mais une fois piqués au vif, ils se font plaisir :).
[^] # Re: Impressionné
Posté par chimrod (site web personnel) . Évalué à 3.
Maintenant que tu me le dis, je me souviens d'avoir vu quelques bug debian FTBFS , avec dans la signature mail un commentaire sur un cluster de machines destiné à la compilation de la distribution :
(Exemple pris au hasard sur http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625058)
J'aurais jamais pensé faire des tests de compilateur en prenant comme source l'ensemble des paquets d'une distribution !
[^] # Re: Impressionné
Posté par claudex . Évalué à 4.
Je dirais que le fait que ce soit massivement multiarch est déjà un critère car ça entraine du code plus portable. Il y a aussi les scripts de compilations déjà fait (contrairement à LFS) commme dit plus haut. Enfin, il y a des choix par défaut qui sont là pour tout le monde (contrairement à Gentoo où il faudrait se poser la question pour chaque paquet) et ça permet de valider le point que Clang est prêt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Impressionné
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2.
Désolé mais le multiarch et le rebuild avec clang n'ont pas grand chose à voir …
Multiarch te permet d'executer de manière native un code i386 sur un OS 64 bits (par exemple). Pour les packages, le travail de multiarch n'est pas lié au code mais à des questions de chemin d'installation.
[^] # Re: Impressionné
Posté par claudex . Évalué à 3.
Je ne parlais pas du projet multiarch (j'avais oublié son existence) mais du fait que Debian est disponible pour beaucoup d'architectures.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Impressionné
Posté par benoar . Évalué à 7.
Je pense que le nombres de paquets et d'architectures couverts font que c'est un projet intéressant quand tu veux étrenner une nouvelle technologie sur un maximum de cas possibles. Et comme tout est automatisé, tu t'offres une couverture énorme pour assez peu d'efforts.
[^] # Re: Impressionné
Posté par zebra3 . Évalué à 5.
Et pourtant elle fournit tout ce qu'il faut pour, comme expliqué ici. Je l'ai encore fait récemment pour ajouter une option de compilation à un paquet (pour l'anecdote, je voulais me connecter à des hôtes VMware avec le shell de libvirt, et ça marche plutôt bien pour les tâches de base).
Il y a même de quoi empaquetter soi-même le noyau.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Impressionné
Posté par gnumdk (site web personnel) . Évalué à -2.
Ca n'en reste pas moins un merdier monstre … Enfin, pas pire que rpm mais quand on voit ce qui se fait ailleurs…
[^] # Re: Impressionné
Posté par William Steve Applegate (site web personnel) . Évalué à 6.
Quel merdier monstre ?
apt-get source machinetpdebuild, c'est pas très compliqué (et je trouve ça plus sympa que RPM lorsque tu veux modifier un truc dans les sources). Pareil pour la création de dépôts, il y a des outils simples et efficaces (j'utilise Falcon pour ma part même s'il n'est plus maintenu depuis des lustres).Ensuite, qu'il y ait mieux ailleurs, peut-être, mais tu ne dis pas où. Pour avoir essayé FreeBSD, par exemple, j'ai trouvé leur système lourdingue (protocole CVSup qui casse les pieds avec les pare-feux restrictifs, arbre des ports gigantesque stocké localement, etc.). À quel OS ou distribution pensais-tu ?
Envoyé depuis mon PDP 11/70
[^] # Re: Impressionné
Posté par gnumdk (site web personnel) . Évalué à 2.
ArchLinux ?
[^] # Re: Impressionné
Posté par Aissen . Évalué à 2.
Perdu! http://packages.qa.debian.org/w/wayland.html
Mais je suis d’accord avec toi pour pulseaudio, systemd, selinux, plymouth (tous plus ou moins dispos dans debian, mais bien moins intégrés), etc.
Par contre Debian innove aussi avec le multiarch par exemple, cf: https://lwn.net/Articles/482952/
[^] # Re: Impressionné
Posté par claudex . Évalué à 3.
Je doute quand même qu'il soit dans la prochaine stable.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Impressionné
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Il faut savoir que pas mal de nouvelle fonctionnalité ne sont jamais ou très peu testé sur d'autres architecture que le x86… Du coup, l'intégration dans debian prends plus de temps en partie parce que cela bogue tout simplement…
Et puis bon, il y a des trucs qui n'était clairement pas mature… Par exemple, systemd n'est clairement pas mature pour remplacer le système actuel chez debian. Au final, debian et fedora sont bien complémentaire.
[^] # Re: Impressionné
Posté par Maclag . Évalué à 10.
La réponse est peut-être dans le titre de la page d'accueil du projet:
"Le système d'exploitation universel".
Oui, Debian possède une grosse base d'utilisateurs, mais aussi de développeurs.
Et effectivement, l'orientation est moins vers le développement de nouvelles technos (comme cité ailleurs, Wayland peut avoir un paquet, ça ne veut pas dire que Debian participe officiellement au développement de Wayland!) que vers le côté "universel".
C'est un peu comme différents niveaux d'abstraction:
Debian est-elle une "simple" distro Linux?
Non, c'est un système d'exploitation universel. Il ne devrait donc pas être dépendant du noyau Linux: hop, on tente un portage vers un noyau BSD (sans oublier Hurd)
Pourquoi Debian devrait être dépendante d'un compilateur particulier? Ça fait pas très universel.
Alors recompilons sous LLVM.
Alors Debian ne remplace pas des projets tels que Fedora qui tirent les nouvelles technos, mais rien ne remplace Debian pour ce qui est de "l'assainissement du code".
Et avoir un très très gros nombre de paquets, d'utilisateurs et de développeurs fait que c'est sans doute la distro la plus adaptée à ce genre de tests. (Tout comme on pourrait dire que le mode de fonctionnement de Fedora en fait la distro "expérimentale" par excellence).
# compil only
Posté par M . Évalué à 2.
Il me semble que le projet a seulement testé la compilation, mais il est dommage de ne pas avoir testé la version généré.
En effet il peut avoir des pb qui passe à la compil mais qui donne un programme non fonctionnel.
[^] # Re: compil only
Posté par ckyl . Évalué à 3.
C'est la limite des distros et de la compilation de projet tiers en général. Tout ce qui a trait aux tests unitaires / fonctionnels / intégration n'est pas standardisé et nécessite au mieux la configuration d'environnements complexes. Ca c'est dans le meilleur des cas. Dans la vraie vie je prend le pari que plus de 60% des projets empaquetés n'ont pas la moindre suite de test valable.
Bref c'est l'usage courant dans le libre et dans les distros depuis toujours. ./configure && make install et ca devrait marcher. Tu t'es déjà posé la question de savoir si un logiciel que tu as compilé marchait correctement ? Tu penses que les maintainers font plus que regarder si ca a l'air de marcher ? Les distribs sources font-elles passer les tests ? La réponse est toujours non. Ils ne font ni mieux ni pire que tout le monde. Les utilisateurs remonteront les bug reports au besoin.
[^] # Re: compil only
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Quand les développeurs font l'effort d'inclure une cible « test » (ou check, ou regression, etc.) à leur Makefile, les empaqueteurs sont censés l'utiliser ; mais c'est vrai que ça reste rare…
[^] # Re: compil only
Posté par M . Évalué à 2.
Sans aller aussi loin rien que booter sur la distro et/ou utiliser quelques programmes serait un bon test.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
# ca compil
Posté par jemore . Évalué à 5.
Cela signifie que Clang/LLVM peut aussi compiler GCC ? Et est-ce que GCC peut compiler Clang/LLVM ?
Peux-t-on recommencer indéfiniment ce cycle de compilation de compilateur ?
[^] # Re: ca compil
Posté par Tobu . Évalué à 5.
GCC se bootstrappe en plusieurs étapes. Si Clang est utilisé, il ne servira que pour la première, et un mini-gcc ira compiler le GCC complet.
# On le fait depuis un moment sous FreeBSD
Posté par Bapt (site web personnel) . Évalué à 10.
Pour information on fait la même choses sous FreeBSD depuis un moment: http://wiki.freebsd.org/PortsAndClang avec des résultats plutôt meilleur que ce à quoi on aurait pu s'attendre, biensûr nous remontons aussi upstream les patchs et généralement ils sont bien accueillis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.