Journal Debian recompilée avec Clang/LLVM

Posté par (page perso) . Licence CC by-sa
Tags :
30
6
mar.
2012

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 (page perso) . Évalué à  10 .

    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

    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 (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Ca fait du bien...

        Posté par (page perso) . É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 . É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 . É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 . Évalué à  2 . Dernière modification : le 06/03/12 à 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 . É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 . É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 (page perso) . Évalué à  7 .

            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,

            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 . Évalué à  4 .

              là effectivement, c'est dommage :/ (je trouve même ça très con comme comportement)

    • [^] # Re: Ca fait du bien...

      Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à  8 .

      Pourquoi Debian et pas une autre distribution ?

      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 (page perso) . É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 :

        About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
        of the Grid'5000 platform, using a clean chroot. Internet was not
        accessible from the build systems.

        (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 (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Impressionné

        Posté par (page perso) . É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 (page perso) . É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.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Impressionné

      Posté par . É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 . Évalué à  5 .

      La distribution n'est pas connue pour être orientée compilation

      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 (page perso) . É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 (page perso) . Évalué à  6 .

          Quel merdier monstre ? apt-get source machin et pdebuild, 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 . Évalué à  2 .

      Non pas pour intégrer de nouvelles technologies (pulseaudio, Wayland)

      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 (page perso) . Évalué à  3 .

        Je doute quand même qu'il soit dans la prochaine stable.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Impressionné

        Posté par (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . Évalué à  2 .

        Sans aller aussi loin rien que booter sur la distro et/ou utiliser quelques programmes serait un bon test.

      • [^] # Re: compil only

        Posté par . Évalué à  0 .

        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

        La conférence "Re-thinking system and distro development", par Lars Wirzenius, au Fosdem 2012 devrait t'intéresser. Il parle de ce processus de tests et d'intégration continue, entre autres, comme un souhait de sa part pour Debian, de manière à produire du code mature et gérable, car on arrive aux limites de la gestion humaine avec le fonctionnement actuel.

        J'ai trouvé l'histoire un peu molle au début, mais je me suis régalé, un délice.

  • # ca compil

    Posté par . É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 . É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 (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.