Campagne de dons pour le compilateur PCC

Posté par . Modéré par patrick_g.
Tags :
15
10
nov.
2008
Technologie
PCC est un compilateur C qui a tout pour séduire car il a pour objectif principal de rester simple, petit, rapide et compréhensible. Il prend en charge la norme C99 et est publié sous licence BSD. Pour mener à bien le développement de ce compilateur le développeur principal, Anders Magnusson (ragge), a besoin de financements. Ainsi il pourra être en mesure de sortir la version 1.0.

Ce compilateur est disponible pour toutes les variantes*BSD, mais également pour Linux, Mac OS X et Windows. Il est capable de générer du code pour de nombreuses architectures comprenant i386, PowerPC, ARM, ainsi que neuf autres machines un peu moins courantes.

Beaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer. Il est d'ailleurs inclus dans l'arbre des sources de projets comme OpenBSD et NetBSD depuis plus d'un an. En terme de performance, ce petit compilateur est capable de produire des exécutables 15 fois plus rapidement que ceux de GCC (seulement 5 fois plus rapidement si l'on active les tests internes de validité, les « sanity checks »), pour une vitesse d'exécution environ 10% plus lente. Cette relative lenteur s'explique par le fait que PCC ne fait des optimisations que sur l'allocateur de registres (alors que l'on peut en faire à plein d'autres endroits). De nombreuses améliorations sont à faire ou à terminer, c'est pourquoi le projet à besoin de votre aide. Historique

Portable C Compiler a originellement été écrit par Stephen C. Johnson des laboratoires Bell vers la fin des années 70. Il a été le compilateur préféré sur System V et sur les version 4.x de BSD. Il n'a été remplacé par GCC qu'en 1994 avec 4.4BSD.

Depuis 2002, le code source a subi un gros nettoyage et plus de la moitié à été réécrit. Ainsi la version actuellement disponible est une modernisation de ce compilateur.

Plan pour la version 1.0

Les dons permettront de faire avancer grandement le projet. Voici la liste des tâches prévues :
  • Amélioration de la conversion vers la forme Static Single Assignment.

    SSA est une représentation intermédiaire permettant entre autre de réaliser des optimisations. La conversion des arbres d'expressions d'une fonction en une forme SSA et vice-versa requiert :
    • la création d'un graphe de flux de contrôle (CFG) ;
    • la construction d'un arbre dominant ;
    • le calcul de la frontière de dominance ;
    • les fonctions d'insertions phi ;
    • la re-numérotation des variables temporaires.

  • Amélioration de la prise en charge des fonctionnalités de la norme C99.

    De nos jours, la norme C99 est probablement la norme du C la plus utilisée. Elle a introduit quelques fonctionnalités qui peuvent simplifier la vie des programmeurs mais qui ne sont pas encore disponibles dans PCC :
    • amélioration des nombres complexes : prise en charge des types de données _Complex et _Imaginary ;
    • amélioration des tableaux dynamiques dans les entêtes/prototypes : la prise en charge des tableaux automatiques à taille variable (variable-length arrays) existe déjà mais pas pour les prototypes de fonctions ;
    • amélioration des déclaration abstraite dynamique : prise en charge de la possibilité d'utiliser les déclarateurs abstraits (abstract declarators) partout dans le code.

  • Amélioration de la compatibilité avec GCC

    Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC :
    • attribute() : prise en charge de la syntaxe de attribute() et contrôle des extensions couramment utilisée ;
    • typeof() : prise en charge du mot clé typeof() ;
    • plage de nombres du mot clé case : prise en charge des plages de nombres donnés à l'instruction case ;
    • énumération incomplète : prise en charge de la déclaration avancée des enums ;
    • champ anonyme dans les structures et unions : prise en charge de l'utilisation des membres anonymes compatible à la fois avec GCC et son utilisation historique.

  • Portage de PCC sur l'architecture amd64.

    Tout reste à faire pour cette architecture de plus en plus courante :
    • mise en œuvre du générateur de code ;
    • mise en œuvre du générateur de code FPU (pour les calculs à virgule flottante) ;
    • mise en œuvre du générateur de code PIC (utilisé pour charger le code des bibliothèques logicielles).
Financement

Les dons se font par l'intermédiaire de l'association « BSD Fund » qui fonctionne de la même manière que « Linux Fund ». Elle a pour objectif de financer les projets, événements et initiatives en rapport avec les systèmes BSD.

L'objectif de la campagne de dons de PCC est de 12 000 dollars (soit environ 9 329 euros). L'argent sera versé à Anders Magnusson après que l'ensemble des points ci-dessus aient été complétés.
  • # Alternative ?

    Posté par (page perso) . Évalué à 9.

    >>> Beaucoup voient en lui une alternative viable à GCC qui pourra à terme le remplacer

    Heu...alternative peut-être...mais uniquement si on veut compiler du C !
    Pour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?

    >>> pour une vitesse d'exécution environ 10% plus lente

    Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.

    Quand à la motivation du projet PCC il est certain qu'une situation de monopole n'est jamais saine. GCC a beau être un superbe soft il vaut mieux pour le logiciel libre que des alternatives émergent (on pense à LLVM par exemple). PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance.
    Je ne peux toutefois m'empêcher de trouver curieuse la justification apportée par Theo de Raadt dans cette interview d'octobre 2007: http://www.thejemreport.com/content/view/369/

    Je cite : "What other hurdles remain in replacing GPL-licensed programs in OpenBSD?

    TdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem..."
    .

    Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
    Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
    • [^] # Re: Alternative ?

      Posté par . Évalué à 7.

      Je crois qu'un autre (enfin c'est un bout de celui que tu cites) argument est que GCC est vraiment un gros bazar monolithique difficile à maintenir (même si il l'est effectivement).

      Tout comme un objectif de LLVM était de faire un truc un peu plus modulaire (si je ne me trompe pas, je suis pas un pro de tout ces trucs), je pense que PCC va aussi essayé de répondre à cette problématique.
    • [^] # Re: Alternative ?

      Posté par (page perso) . Évalué à 10.

      À propos de gcc j'avais entendu dire que son architecture avait volontairement été rendu moins pratique par Sallman, pour rendre plus difficile les extension propriétaires. Est-ce que que quelqu'un serait dire si cela à un fond de vérité ou si il s'agit de pure légende urbaine (si on peu qualifier un sujet aussi pointu d'urbain…) ?

      [HS]
      Mon premier message écrit tout en bépo sur linufr ! Bon je suis encore loin de ma vitesse de frappe en AZERTY.
      [/HS]
      • [^] # Re: Alternative ?

        Posté par (page perso) . Évalué à 10.

        >>> À propos de gcc j'avais entendu dire que son architecture avait volontairement été rendu moins pratique par Sallman, pour rendre plus difficile les extension propriétaires. Est-ce que que quelqu'un serait dire si cela à un fond de vérité ou si il s'agit de pure légende urbaine

        C'est la vérité vraie (même si le mail ou il déclare ça date de 2000):

        http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html

        Y'avait eu une discussion sur LWN ou j'avais aussi posté le lien vers ce mail et il y a des commentaires intéressants:
        http://lwn.net/Articles/301135/
        • [^] # Re: Alternative ?

          Posté par . Évalué à 5.

          N'est-ce pas choquant ?

          Je sais bien que Stallman est très attaché à l'aspect éthique du logiciel libre, mais de là empêcher une solution plus pratique et qui rendrait le logiciel meilleur pour de tels motifs... J'imagine que Stallman est aussi opposé aux modules Linux :)
          • [^] # Re: Alternative ?

            Posté par . Évalué à 5.

            >N'est-ce pas choquant ?

            Choquant dans quel sens? Surprenant?
            Non, c'est cohérent pour RMS..

            Réfléchi à ce qu'a impliqué la création de la license GPL par rapport aux logiciels libres qui existaient déjà sous license BSD, MIT: plutôt que de contribuer aux logiciels libre existant, c'est créer une incompatibilité afin d'avoir une license qui (du point de vue de RMS) défend mieux les droits des utilisateurs.

            C'est la même chose ici.

            On est d'accord ou pas avec RMS, mais il est assez cohérent dans ses actions d'après ce que j'en sais.
            • [^] # Re: Alternative ?

              Posté par (page perso) . Évalué à 2.

              Je ne trouve pas l'exemple pertinent. Réécrire les logiciels sous GPL, ça n'empêche en rien de les écrire en essayant d'en faire une implémentation propre et avec une architecture qui vise l'efficacité technique.

              Maintenant je ne sais pas si choisir une architecture logiciel moins bonne techniquement à été un bon choix politique, peut être. Moi je comparais plutôt ça au fait de pousser theorra pour la vidéo sur internet alors que celui-ci est loin d'être la meilleur solution technique.
              • [^] # Re: Alternative ?

                Posté par . Évalué à 2.

                Re-écrire plutôt que de contribuer a l'existant pour une quantité d'homme-heure donnée donne un résultat inférieur sur le plan technique car il y a duplication du code (sauf dans le cas particulier ou l'existant est pourri mais ce n'était pas la raison utilisé pour coder un OS sous license GPL plutot que de contribuer à *BSD).


                Sinon pour theora, tu pense à quoi comme meilleur solution technique?

                Dirac? Il est très gourmand au niveau CPU donc je ne suis pas convaincu que ce soit une bonne idée de l'utiliser pour diffuser des vidéos sur Internet et les autres formats ont des problèmes de brevets logiciels aux USA.
                • [^] # Re: Alternative ?

                  Posté par (page perso) . Évalué à 3.

                  Sinon pour theora, tu pense à quoi comme meilleur solution technique?

                  H264/AVC, et de loin.

                  et les autres formats ont des problèmes de brevets logiciels aux USA.

                  Ce n'est pas technique, donc non éliminatoire pour le poste de meilleure solution technique.

                  Sinon, ben on fait avec ce qu'on a, soit Theora pour le présent, Dirac pour le futur.
    • [^] # Re: Alternative ?

      Posté par . Évalué à 7.

      Heu...alternative peut-être...mais uniquement si on veut compiler du C !

      Euh ... C'est certainement ce dont ont besoin de nombreux projets comme les BSD .... Avoir un compilateur qui compile tout et fait le café c'est bien, mais pour la base d'un OS écrit en C, c'est peut-être pas utile ....

      Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.
      Fais-la, fais le bench puisque tu sembles aussi sur de toi ...

      Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre.

      Euh ... OpenBSD a audité/réécrit une grosse partie du code de OpenBSD en ayant pour objectif la sécurité. Faire la même chose pour le compilateur qui génère le code semble bien compliqué pour une "usine à gaz" tel que GCC. Par contre un compilateur plus simple permettrait aux équipes OpenBSD de le maintenir eux-même ou au moins de remonter les problèmes rencontrés plus facilement ..... C'est l'intérêt majeur d'un tel projet .....

      Je vois bien les deux compilateurs cohabiter sans problème ... tout au moins pour les BSD .. PCC chargé de compiler le système de base, et GCC s'occuper des logiciels supplémentaires, qui eux ne sont pas forcément écrit en C.
      • [^] # Re: Alternative ?

        Posté par . Évalué à 6.

        >Fais-la, fais le bench puisque tu sembles aussi sur de toi ...

        Ahem, en science c'est à celui qui fait une affirmation de la prouver et non pas le contraire..

        Affirmer "[PCC fournit] une vitesse d'exécution environ 10% plus lente [que GCC]" sans benchmark: ca n'a pas grande valeur..

        J'imagine que ce chiffre n'est pas sorti au hasard, donc il doit y avoir quelque chose derriere pour le justifier.

        Cela dit les besoins d'un OS sont très particulier et Linus lui-même rale relativement souvent contre gcc qui casse du code en 'sur-optimisant'.
        • [^] # Re: Alternative ?

          Posté par . Évalué à 4.

          Au niveau des performances, voilà ce qu'en dit Anders Magnusson :
          http://undeadly.org/cgi?action=article&sid=2008110813583(...)
          • [^] # Re: Alternative ?

            Posté par . Évalué à 2.

            Je rêve ou on se fout de nous :

            > Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.

            Yes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95.
            • [^] # Re: Alternative ?

              Posté par . Évalué à 3.

              Je rêve où tu fais exprès de volontairement couper la réponse de ragge qui contient les vrais chiffres ?

              I used bytebench. Hm, a rerun on some of the passes shows that the difference is not much more against gcc 3.3.5 with -O2:


              Test pcc -O gcc -O2 % of gcc performance
              dhry2 1197813 1359242 88%
              int 168286 186189 90%
              float 190144 192564 99%
              arithoh 2264451 3354473 67%
              short 198920 198930 100%
              double 145081 192597 75%
              ---
              Average 87%

              The cases where pcc is significantly slower is missing optimizations like strength reduction etc.
              • [^] # Re: Alternative ?

                Posté par . Évalué à 2.

                e rêve où tu fais exprès de volontairement couper la réponse de ragge qui contient les vrais chiffres ?
                oui, je parle du bench des 10% plus lent que gcc.
                Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.

                PS : je ne parle même pas du fait que -O2 est utilisé au lieu de -O3.
                • [^] # Re: Alternative ?

                  Posté par . Évalué à 5.

                  > Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.

                  Cette remarque au sujet la version de gcc ne manque pas d'ironie. Il est plus que probable que ragge utilise cette version parce que c'est celle qui est incluse dans OpenBSD pour les architectures i386 et amd64. C'est une vieille version parce qu'ils (les devs. d'OpenBSD) n'arrivent pas à suivre le rythme et à maintenir eux-même les versions plus récentes de gcc (les devs. de gcc ne maintiennent pas le port OpenBSD pour eux). Ce qui explique qu'ils cherchent une porte de secours...

                  Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement, où quelques "low hanging fruits" sont encore à portée de main.
                  • [^] # Re: Alternative ?

                    Posté par . Évalué à 2.

                    Hum, 3.3.5 c'est du vieux quand même ;)
                    C'est avant la réarchitecture de GCC (et c'est vrai que si quand ils disent que le code de GCC est dégueu, c'est du code de GCC3 qu'ils parlent, je les comprends).
                  • [^] # Re: Alternative ?

                    Posté par (page perso) . Évalué à 2.

                    >>> Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement

                    C'est vrai que cela n'est pas ridicule sur ce benchmark.
                    N'oublions pas toutefois que GCC 3.3.5 est loin, très loin, d'être une version récente. Depuis ce vénérable ancêtre de 2004 il y a quand même eu un paquet de versions de GCC :

                    GCC 3.3.6
                    GCC 3.4.0
                    GCC 3.4.1
                    GCC 3.4.2
                    GCC 3.4.3
                    GCC 3.4.4
                    GCC 3.4.5
                    GCC 3.4.6
                    GCC 4.0.0
                    GCC 4.0.1
                    GCC 4.0.2
                    GCC 4.0.3
                    GCC 4.0.4
                    GCC 4.1.0
                    GCC 4.1.1
                    GCC 4.1.2
                    GCC 4.2.0
                    GCC 4.2.1
                    GCC 4.2.2
                    GCC 4.2.3
                    GCC 4.3.0
                    GCC 4.3.1
                    GCC 4.3.2

                    Et la toute nouvelle version 4.4 est sur le point de sortir. Comparer les perfs de PCC avec GCC 3.3.5 est donc biaisé (mais on est d'accord que c'est la version présente dans l'arbre des ports d'OpenBSD donc c'est ça qui compte pour eux).
                    • [^] # Re: Alternative ?

                      Posté par (page perso) . Évalué à 8.

                      Sans faire de commentaire sur le fond du débat, mais ta liste ne représente strictement rien...

                      Quelle quantité d'amélioration y a-t-il dans chaque version que tu cite ? Est-ce que l'équipe de Gcc fais une nouvelle version à chaque correction d'une faute d'orthographe ? Est-ce qu'il y a une nouvelle version à chaque fois que l'amélioration de perf atteint 10% de gain par rapport à la précédente ?

                      Bref, ce n'est pas parce qu'il y a eu de nombreuse version depuis la 3.3.5 que les perfs sont meilleur. Donc, on a des bench par rapport à la 3.3.5 et ces tout. Pour avoir des infos face au dernières version, il faut là aussi faire des benchs.
                      • [^] # Re: Alternative ?

                        Posté par . Évalué à 3.

                        Bonjour

                        Pourquoi ne pas demander un support de TCC dans CompBench ? (c' est un benchmarker de compilation selon scénarios -appli déclarées, etc etc-). Avec le fonctionnement de CompBench, vous auriez un ensemble de résultats pouvant être comparé, entre GCC x.x et TCC, non ?

                        CompBench :
                        http://compbench.sourceforge.net/cgi-bin/index.cgi

                        En plus, c' est le bon moment pour demander une feature comme la prise en charge de PCC
                        (Peut être même la branche Melt de Gcc ? Voir le compilateur TCC de Mr Bellard)

                        Cdlt.
            • [^] # Re: Alternative ?

              Posté par . Évalué à 10.

              Disclaimer : je ne suis pas OpenBSDiste.

              Je ne pense pas qu'on se foute de nous, juste qu'il ne faut pas perdre de vue l'optique selon laquelle ces benchs ont été effectués.

              PCC a vocation à remplacer le compilateur de base par défaut d'OpenBSD. Ce dernier fut jusqu'à relativement récemment*, si je ne m'abuse, un GCC 2.95 assez lourdement modifié pour gérer certaines choses, en particulier certaines formes de vérification dynamique servant à contrer les attaques par débordement & co. Je crois que maintenant c'est un 3.3, avec le 2.95 uniquement pour certaines architectures matérielles. Il est donc parfaitement logique et cohérent de comparer avec ces vieilles versions de GCC pour évaluer pragmatiquement l'impact sur OpenBSD.

              Par contre, généraliser à « PCC est seulement 10% plus lent que la dernière version de GCC », c'est à mon avis naïf, voire mensonger.

              <voyance>Selon moi l'écart va avoir tendance à se creuser, GCC me semblant être en train de décoller dans la recherche académique, et à bouger peut-être un peu plus vite sur certains points (passage au C++ selon la proposition d'Ian Lance Taylor ?). Les effets bénéfiques de la concurrence pure et non faussée :-) ?</voyance>

              * : Un GCC plus moderne est évidemment disponible dans les ports.
    • [^] # Re: Alternative ?

      Posté par . Évalué à 10.

      Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
      Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.


      Il me semble avoir lu plusieurs fois des commentaires de Marc Espie se faisant remarquer que seules les architectures x86 et powerpc étaient correctement maintenues et qu'ils avaient régulièrement des problèmes pour les architectures plus exotiques. D'autre part, les dev OpenBSD se plaignent de la difficulté à faire inclure des patchs.

      Voir par exemple http://undeadly.org/cgi?action=article&sid=2007091519520(...)


      Étienne
    • [^] # Re: Alternative ?

      Posté par . Évalué à 10.

      >Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre
      [...]
      > Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.

      Il apparait que TdR en sait un poil plus long que toi sur les compilos et la façon dont ils sont maintenus. Un boût de phrase, évident mais implicite t'aurait sans doute aidé à comprendre ce dont parle Théo : il n'est pas assez maintenu ... pour les choses qui importent à OpenBSD.

      En l'occurrence, OpenBSD se traine sur certaines plateformes un vieux gcc 2.95 (et les autres sont restées en 3.3, d'ailleurs) parce que support par le gcc "upstream" a été délaissé. Le support pour la plateforme OpenBSD est lui aussi, bien entendu, à la charge des devs OpenBSD : les grosses boites qui paient des développeurs à plein temps pour améliorer gcc n'ont que fiche des OpenBSD sur Vax et archis pour bricoleur dinosaures. Le m68k n'est sans doute plus assez corporate. Ces grosses boites font évoluer le logiciel, très vite (ce qui est d'autant plus dur à suivre, du coup), précisément, et l'écart à rattraper pour maintenir les fonctionnalités _qui importent à OpenBSD_ se creuse chaque jour.

      Ce mode de fonctionnement est tout à fait justifié de la part de gcc, mais il explique aussi le malaise de certains développeurs qui doivent de facto assurer pendant leurs loisir le maintient d'un code qui change très vite, qui change d'une façon qui ne respecte en rien leurs besoins, un code vieux de 23 ans de patchs accumulés, un code qui est volontairement structuré pour ne pas être modulaire.
      • [^] # Re: Alternative ?

        Posté par (page perso) . Évalué à -2.

        Donc ton avis c'est que les fonctionnalités qui importent vraiment à OpenBSD c'est la compatibilité avec VAX et m68k ?
        C'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque, tellement monstrueux que ça vaut le coup de garder une version 2.95 ;-)

        Bon trêve de plaisanterie. TdR veut un compilo simple et qui intègre les modifs du projet OpenBSD. Il est évident que GCC ne réponds pas à ces critères et il est donc légitime de sa part de chercher ailleurs. Tout le monde comprends ça....mais pas besoin de sa part de troller en disant que GCC est un projet qui n'est pas maintenu upstream.
        • [^] # Re: Alternative ?

          Posté par . Évalué à 10.

          > C'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque [...]

          Mais bon sang, on parle d'un OS d'amateurs, de gens qui développent pour le plaisir, alors oui, Vax est capital, et ils y consacrent du temps. Tu semble ne pas le croire, mais ça l'est vraiment, pour eux, au moins.

          En tout cas parler de "marché", fut-ce au figuré, montre où se niche la confusion. C'est précisément là où se trouve le sel des BSD (et certainement où devait être le fun dans le petit monde de Linux avant 1998 environ) : une petite famille, peu de développeurs, tous sont connus, peu de patchs (on peut suivre les changements), bref des projets à taille humaine ; un engouement pour les vieilles machines, du code pour le plaisir du code (ou pour sa beauté, sa simplicité avant son efficacité, par ex.) comme de l'art pour l'art, ou plutôt de l'artisanat, et vraiment rien de corporate. Pas de "marché". GCC pour sa part est touché par l'excès inverse.

          D'ailleurs, cette propriété en soi ça suffit à expliquer ce travail sur PCC (bien que ça ne soit pas la seule raison) : même s'il est probable que ça fasse un compilateur plus lent et moins complet, il y a un certain nombre de développeurs qui ont envie de mettre les mains dans les entrailles d'un compilateur au code clean et à dimension humaine. Juste pour le plaisir du bricolage, de l'amateurisme éclairé.
          • [^] # Re: Alternative ?

            Posté par . Évalué à 4.

            Un exemple qui montre bien le coté traditionnaliste d'OpenBSD est qu'ils ont réimplémenté CVS..

            Ayant (ab)usé de CVS je comprends ce qui les attire: c'était un logiciel ou si tu as corrompu certaines donnée, tu peux lancer un vi et corriger à la main.

            Mais ceci dit je considère quand même que c'est un logiciel qui a fait son temps et si j'avais à choisir un logiciel de gestion de configuration j'irais plutôt voir du coté de Mercurial (git m'a l'air compliqué a utiliser) que de CVS..
            • [^] # Re: Alternative ?

              Posté par . Évalué à 2.

              Cela dit, si CVS est un outil qui leur convient, et si le besoin se fait sentir d'améliorer ledit outil en produisant une autre version, pourquoi pas ? Après tout, leur OpenNTPD n'est pas mal du tout :-)
            • [^] # Re: Alternative ?

              Posté par (page perso) . Évalué à 4.

              L'avantage de CVS, c'est qu'il est écrit en C, et peut donc être inclus dans le système de base.
    • [^] # Re: Alternative ?

      Posté par (page perso) . Évalué à 10.

      Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
      Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.


      Gcc a laissé tomber des architectures toujours maintenues dans OpenBSD, de ce point de vue on peut pas dire que gcc est maintenu.
      Je t'invite à lire les commentaires de Marc Espie sur gcc.

      http://undeadly.org/cgi?action=article&sid=2007091519520(...)

      les pixels au peuple !

  • # pas tout jeune

    Posté par (page perso) . Évalué à 6.

    j'ai bossé dessus en 1986( ce qui ne me rajeunit pas :-( ) et il y avait à l'époque déjà beaucoup de choses à améliorer ! ceci dit, je pense que gcc est pour l'instant sans égal et la vitesse de compilation est quand même assez anecdotique avec les CPU monstrueux dont on dispose maintenant.
    • [^] # Re: pas tout jeune

      Posté par . Évalué à 6.

      > la vitesse de compilation est quand même assez anecdotique avec les CPU monstrueux
      > dont on dispose maintenant

      justement, dans le cas d'un projet comme les *BSD, ce n'est pas anecdotique. Il y a plusieurs architectures à maintenir et à compiler. Pour un même code, le temps de compilation entre gcc3 et gcc4 a pu doubler. Certes on peut arguer du fait que oui, maintenant on a des proco rapides, mais d'une part il n'est pas tjs facile de mettre à jour le matériel à son bon gré (problème de fonds) ni non plus sage: cela permet de cacher un constat médiocre, i.e. doubler à machine égale le temps d'exécution d'une tâche est une régression sévère.
      • [^] # Re: pas tout jeune

        Posté par . Évalué à 10.

        doubler à machine égale le temps d'exécution d'une tâche est une régression sévère

        Si et seulement si on parle bien de la même tâche. Le fait que GCC4 est plus lent à compiler que GCC3 peut également signifier qu'il fait mieux son travail (code mieux vérifié, mieux optimisé, ...)
      • [^] # Re: pas tout jeune

        Posté par . Évalué à 8.

        oui mais si les utilisateurs finaux ont un système dont les binaires s'exécutent 10 % plus lentement, ce n'est pas une régression quelque part ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: pas tout jeune

        Posté par (page perso) . Évalué à 6.

        le temps de compilation entre gcc3 et gcc4 a pu doubler

        Et c'est super pénible, surtout en C++
        Ca ralentit énormément la productivité (processus modification code - compilation - test) et ca donne envie d'utiliser des langages interprétés.
        Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial. Rien n'empêche après de fournir un binaire à l'utilisateur compilé avec GCC et toutes les optimisations qui vont avec.
        • [^] # Re: pas tout jeune

          Posté par (page perso) . Évalué à 3.

          « le temps de compilation entre gcc3 et gcc4 a pu doubler (...) Et c'est super pénible, surtout en C++ (...) et ça donne envie d'utiliser des langages interprétés. »

          Tiens, c'est exactement pour ça que je suis passé du C++ au Python :-) Le C++ est quand même un cas particulier avec ses horribles templates qui augmentent considérablement le temps de compilation. D'ailleurs, il me semble que les autotools n'exploitent toujours pas la précompilation des entêtes C++ :-( Quand j'utilise Borland C++ Builder, la précompilation des entêtes faisait passer le temps de compilation de 5/10 minutes à 60 secondes.
        • [^] # Re: pas tout jeune

          Posté par (page perso) . Évalué à 2.

          >>> Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial.

          Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0) et à la fin de l'écriture du programme on n'a plus qu'a optimiser à fond (-O3).
          • [^] # Re: pas tout jeune

            Posté par (page perso) . Évalué à 4.

            le probleme c'est le c++ moderne qui repose sur des kilometres de templates et de meta-conneries, qui eux même font l'hypothese que "les ptites fonctions et les ptites classes qui font rien c'est pas grave parce que y'a la bonne le compilo qui fait le menage" . Quand l'optimiseur est activé, ça inline effectivement tout ça en éliminant le code mort et ça va vite. Quand l'optimiseur est off tu te retrouve avec un binaire 5x plus gros (10x si en plus t'as mis du -g) , qui du coup met nettement plus de temps à linker, et surtout qui tourne 25x moins vite (et encore ça peut etre pire)
            • [^] # Re: pas tout jeune

              Posté par (page perso) . Évalué à 2.

              Juste pour savoir, c'est pour quel genre de projet que tu utilises du C++ et quelles sont les avantages qu'il te procure pour que les inconvénients que tu cites en vailles la peine ?
              • [^] # Re: pas tout jeune

                Posté par (page perso) . Évalué à 2.

                Le premier avantage c'est que je connais c++ et pas java :)

                Ensuite pour des projets du genre traitement audio en temps-reel ça repond bien aux contraintes de performance, et actuellement tout l'ecosysteme est à 95% en c++ donc ça reste un choix assez naturel. Après c'est vrai que sur d'autres projets j'aurais un peu plus de mal a dire "seul le c++ répond au cahier des charges"
          • [^] # Re: pas tout jeune

            Posté par . Évalué à 5.

            > Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0)

            Parce que c'est bien trop lent de toutes façons (la différence avec ou sans optims est minimale).

            Le projet OpenBSD se fait fort de compiler ses binaires pour toutes les architectures supportées (y compris de _très vieilles archis_) sur la plateforme elle-même. Ce qui évite par ex. de faire comme les devs NetBSD, qui s'aperçoivent parfois des mois après qu'une archi est cassé parce que ça passait bien à la cross-compilation... Et ça permet de stress tester le noyau en cours de développement sur ces architectures : c'est de l'intégration continue, en somme. Évidemment ça marche moins bien quand on a un compilo lent et mal supporté (mal supporté : sur l'archi/plateforme en question, comme tu semble ne pas comprendre...).
          • [^] # Re: pas tout jeune

            Posté par . Évalué à 2.

            Euh, tu compiles deja en mode debug, donc avec les optimisations desactivees...
  • # PCC... déjà pris ce nom

    Posté par (page perso) . Évalué à 2.

    Je pense qu'on va se marrer le jour où quelqu'un va me packager PCC, alors que je package Roadsend PHP Compiler dont l'exécutable se nomme "pcc"...

    http://www.roadsend.com/

    Ca me rappelle mes déboire avec le navigateur "flock" donc un exécutable linux existe déjà mais ne sert pas à la même chose :p
    • [^] # Re: PCC... déjà pris ce nom

      Posté par . Évalué à 1.

      C'est pourtant quelque chose d'assez classique.

      Ne serait-ce que l'exécutable /usr/bin/git qui peut venir de deux paquetages différents:
      - les outils GNU, puisque là GIT signifie GNU Interactive Tools;
      - l'outil de gestion de révisions, cher à Linus, utilisé notamment pour gérer le code du noyau et d'autres projets.

      Ça m'a fait un peu bizarre quand j'ai lancé mon premier " git clone ... " et que je me suis fait réprimander. Il m'a fallu un petit instant pour me rendre compte qu'il ne s'agissait pas du logiciel attendu.

      J'imagine donc que la méprise est commune, et qu'il existe bien d'autres cas !
      • [^] # Re: PCC... déjà pris ce nom

        Posté par (page perso) . Évalué à 1.

        Xpress Dash, un solveur mathématique propriétaire utilisé par certains au boulot, et Debian Alquimist Shell dash, partagent le même binaire "dash". Ça prend un moment la première fois pour comprendre pourquoi le script init.d lance bien un dash mais que ça marche pas comme prévu, à cause d'un souci de $PATH le chemin.
  • # PCC concurrent de GCC ?

    Posté par (page perso) . Évalué à 8.

    Hum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser. Comme dit dans les commentaires précédents, GCC est très portable, rapide, et gère un nombre considérable de langages différents. J'aime beaucoup les avertissements GCC (-Wall -Wextra -Werror). Exemple : il râle si on oublie un argument à printf ou si un argument n'est pas du bon type. Ce genre de détail est un gain énorme en temps de debug !
    http://www.haypocalc.com/blog/index.php/2007/12/03/85-option(...)

    PCC n'est plus maintenu depuis longtemps (Theo semble dire l'inverse, que GCC n'est plus maintenu) : ce n'est que récement que PCC renait de ses cendres. Pour moi, c'est plutôt un coup marketing : OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.

    J'avais dressé une liste (sûrement incomplète des compilateurs C libres) :
    http://www.haypocalc.com/blog/index.php/2007/10/02/77-compil(...)

    Apparement, le seul qui puisse atteindre le niveau de GCC est LLVM. Ce dernier n'est pas spécifique au C, Apple l'utilise déjà pour compiler des shaders (code pour les cartes graphiques). Il sait faire de la compilation à la volée (JIT). Il y a un projet (PyPy) qui l'utilise pour compiler du Python. Bref, rien à voir comparé à la blague qu'est PCC.
    • [^] # Re: PCC concurrent de GCC ?

      Posté par . Évalué à 4.

      Tout à fait d'accord, pour les gens qui veulent un compilateur alternatif BSD, llvm est là. Et c'est bien plus avancé que PCC (quoi pas encore de SSA ?).
      Pour une fois que Apple verse du code :)
    • [^] # Re: PCC concurrent de GCC ?

      Posté par (page perso) . Évalué à 6.

      Est-ce que pcc ne pourrait pas être aussi un moyen d'améliorer son code aussi ? GCC doit bien avoir son lot d'erreurs d'implémentation, et d'après certain commentaires certains code C serait englué dans des comportement propre à GCC. Cela me fait un peu penser aux problèmes du web, et au fond c'est également une question de respect des standards.

      Cela pourrait même mettre en avant des problèmes de GCC et permettre de l'améliorer. Les bien fait d'une saine concurence dirait certains. Évidemment il faut une volonté de part et d'autres de coller au standard et pas d'enfermer dans les spécificités. De ce coté là je pense que ça devrait aller non ?
      • [^] # Re: PCC concurrent de GCC ?

        Posté par . Évalué à 9.

        De ce coté là je pense que ça devrait aller non ?

        Non .....

        Vu les GNUseries que tu trouves dans les outils GNU qui ne sont pas compatibles avec les standards Unix, j'y crois peu ....

        Celà dit ce n'est pas forcément la faute aux outils, mais surtout la façon dont ils sont utilisés .... La portabilité est loin d'être le souci de beaucoup de développeurs de Logiciels Libres.
    • [^] # Re: PCC concurrent de GCC ?

      Posté par . Évalué à 10.

      J'étais certain qu'un tel article (très bien écrit et objectif de surcroit) sur linuxfr déclencherait des commentaires de fanatiques comme celui-ci ou les habituelles baves de patrick_g (qui n'a d'ailleurs pas manqué à l'appel ;) ).

      Pour répondre calmement...

      Hum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser.

      Dans l'article il est parlé d'alternative à GCC au sein du système et pour compiler celui-ci. A quoi cela sert de savoir compiler du fortran, du java, etc. dans la base d'un os ? Pas grand chose.

      GCC sait compiler bon nombre de langages, PCC se concentre sur le C, et c'est en cela qu'il peut représenter une alternative à GCC (ragge parle d'ailleurs d'ajouter plus tard le support d'autres langages comme le C++).

      OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.

      PCC n'a rien à voir avec OpenBSD ou Theo. C'est un projet commun à tous les BSD et l'association en charge de la collecte des fonds s'occupe de tous les BSD sans préférence... D'ailleurs, ragge, le mainteneur de PCC est l'ancien mainteneur de l'archi VAX de NetBSD...

      Bref, rien à voir comparé à la blague qu'est PCC.

      Pourquoi être si insultant ? PCC est un compilateur C petit, portable, très rapide et produisant des binaires relativement bonnes.
      Du fait de ces avantages et de sa licence il a tout pour intéresser les systèmes BSD qui souhaitent avoir un bon compilateur C (et rien d'autre) pour l'os de base... Alors oui, la route est encore longue et PCC n'avait pas été maintenu depuis des lustres... mais tous les projets libres commencent bien un jour non ? Pourquoi tant de haine ?
      • [^] # Re: PCC concurrent de GCC ?

        Posté par . Évalué à 8.

        Pourquoi tant de haine ?

        Parce qu'on est sur trollfr.org, et que dès qu'on peut baver sur du BSD faut pas se priver \o/ ! On connait pas le sujet, donc bavons !

        C'est en partie pour ca que je prends de moins en moins de plaisir à lire les commentaires...
        • [^] # Re: PCC concurrent de GCC ?

          Posté par (page perso) . Évalué à 3.

          >>> On connait pas le sujet, donc bavons !

          Nous serions plus qu'heureux que tu proposes de belles dépêches en relation avec le monde BSD. Cela contribuerait à élever le niveau et à faire connaitre le sujet.
          • [^] # Re: PCC concurrent de GCC ?

            Posté par . Évalué à 8.

            Ah, évidemment l'habituelle réponse 'si ca te va pas contribue'... si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD, et vu les réactions/trolls qui ont suivi j'ai laché l'affaire.. je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)
            • [^] # Re: PCC concurrent de GCC ?

              Posté par (page perso) . Évalué à 4.

              Tiens c'est marrant ça me rappelle mes news freebsd ...
            • [^] # Re: PCC concurrent de GCC ?

              Posté par (page perso) . Évalué à 3.

              >>> si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD

              J'ai regardé avant d'écrire mon post et c'est parce que j'ai vu que tu avais fait la news d'OpenBSD 3.8 que je me suis dit que tu pouvais continuer au lieu de critiquer.

              >>> je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)

              J'ai fais les news OpenBSD 3.9 et OpenBSD 4.0...est-ce à dire que j'ai beaucoup plus de patience et de tact ? Ou bien est-ce parce que ton accusation de baveur anti -BSD à mon encontre est finalement mal fondée ?
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 5.

              Même chose, j'ai quasiment arrêté de parler d'OpenBSD ici, vu le ton des commentaires qui suivent...
              • [^] # Re: PCC concurrent de GCC ?

                Posté par (page perso) . Évalué à 6.

                Ici la critique est généralisée. Mandriva se fait démonter, Ubuntu se fait ratiboiser et ne parlons même pas de Novell/Suse. Tout le monde participe joyeusement à ces discussions critiques sauf les BSDistes qui semblent avoir un attachement religieux à leur OS et qui ne supportent pas la moindre remise en question de leur système.
                Faudrait cesser de jouer les calimero et avoir le cuir un peu plus épais !
      • [^] # Re: PCC concurrent de GCC ?

        Posté par (page perso) . Évalué à 9.

        >>> les habituelles baves de patrick_g

        Mais oui. Des baves du style "PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance" n'est ce pas ?
        Je dis explicitement que le développement de PCC est souhaitable pour le logiciel libre dans son ensemble mais visiblement tu ne lis que ce que tu veux bien lire.

        Je ne sais pas ce qu'ont certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms.
        • [^] # Re: PCC concurrent de GCC ?

          Posté par . Évalué à -2.

          Il faut _aussi_ lire le reste du commentaire. Je sens une certain dénigrement de PCC, et cette phrase ne semble être là que pour édulcorer le reste de tes propos. Ce n'est peut être pas volontaire, mais c'est ce que je "ressens" à la lecture. Aparamment je ne suis pas le seul.
          • [^] # Re: PCC concurrent de GCC ?

            Posté par (page perso) . Évalué à 2.

            >>> Je sens une certain dénigrement de PCC

            Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ? Pour moi c'est juste le rappel d'un fait.
            Si l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.

            En quoi le fait de dire que l'argument selon lequel GCC ne serait pas maintenu est faux est un dénigrement de PCC ? Pour moi c'est juste le rappel d'un fait. Cet argument du manque de développement upstream ne doit pas être utilisé car il est faux.

            En quoi le fait de dire que l'écart de 10% de performances n'est pas soutenu par des benchmarks est un dénigrement ? Pour moi c'est juste le rappel d'un fait. Tant que nous n'aurons pas des benchs comparatifs il est normal et sain d'être quelque peu sceptique au sujet des performances car, de l'aveu même de son mainteneur, PCC n'est pas optimisé.

            Dire que je bave systématiquement sur les BSD est absurde. J'ai écrit pas mal de news sur les OS BSD, sur PC-BSD et j'ai même écrit la news sur LLVM 2.2 qui est un compilateur sous licence BSD : http://linuxfr.org//2008/02/18/23723.html
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 3.

              Il y a l'idée et la façon de l'exprimer .... Pour ma part je ne parle que de ce commentaire :

              Heu...alternative peut-être...mais uniquement si on veut compiler du C !
              Pour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?


              La tournure des phrases .... le "!", et la question posée .... J'ai tendance à employer ce genre de tournure quand j'ai affaire à quelqu'un de mauvaise foi ou quand j'ai un abruti en face de moi ....


              Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture

              La aussi la tournure ..... pas besoin d'insister sur le "J'attends de pied ferme" ...
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 1.

              Si l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.

              Si tu avais lu la news complètement, tu aurais pu voir que la conformance à la norme C99 est un des principaux objectifs de PCC.
              • [^] # Re: PCC concurrent de GCC ?

                Posté par (page perso) . Évalué à 0.

                Un objectif qui n'est pas atteint aujourd'hui. Donc, pour l'utilisateur d'aujourd'hui ayant besoin du C99, PCC n'est pas une alternative.
                • [^] # Re: PCC concurrent de GCC ?

                  Posté par . Évalué à 4.

                  Qui a dit que PCC était prêt ? Tout le monde sait qu'il n'en est qu'au commencement et que la route sera très longue... Je te rappel au passage le titre de la dépêche :

                  Campagne de dons pour le compilateur PCC
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 3.

              >>> Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ?

              GCC = `GNU C Compiler`
              Apès si les gens de GNU sont pas très cohérents et ont choisis le même sigle pour dire `GNU Compiler Collection` ...

              Donc ici on parle du compilateur C ;-)
        • [^] # Re: PCC concurrent de GCC ?

          Posté par . Évalué à 5.

          C' est pourtant simple : regarde ce qu' est devenu GCUsquad, cela peux permettre de se forger une opinion quant aux nouveaux utilisateurs de BSD lisant DLFP ...
          Il y a quelques années, pour un lecteur, GCUsquad était ce groupe dont on osait à peine s' approcher, dont on se délectait des news du site, on était ravi quant DragonflyBSD a eu sa tite mascotte sur le iste... Bref un endroit clean, marrant, carré.
          Regarde aujourdui ce qu' est devenu GCUsquad : le fameux ton des news n' est plus inventif, il n' est devenu qu' un remplaçant au manque d' imagination des nouveaux rédacteurs. Même pas une marque de fabrique tant c' est mal usité aujourdhui.
          Bref les petits nouveaux chez GCUsquad ne valent pas mieux que les petits nouveaux ailleurs en ce moment. Avec la particularité du "j'me'la'pete'je'suis'gcu". Bref GCUsquad a chuté sévère... A cause certainement d' un récente trop grande ouverture ala "viendez maintenant, plus besoin d' être un guru pour être à la gcu" ben voilà... ils les ont, leurs nouveaux... du genre à porter le t-shirt OpenBSD toute l' année, mais même pas avoir un *bsd installé chez eux... ou alors dans une vm.
          Parcequ' a l' origine ils se sont ouverts pour des types comme moi, juste des users, voilà le résultat...

          Donc faut pas généraliser, Patrick_g :
          certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms CERTAINS et pas tous, effectivement :D

          HS : Bref, tout le monde semble victime de la "démocratisation" (humhum). Là où ça fait le plus 'mal', ce n' est pas pour une gcu qui baisse en niveau (au regard des users qui se prennent pas pour) mais c' est plutôt dans notre presse (Diamonds Edition) où on matraque le lecteur à coup de photos d' écrans avec toujours la même distribution, toujours le même bureau, et toujours le même wm. Chez Diamond, on ne démocratise même plus, on matraque...

          (gcu et diamond dans le même commentaire, ça va moinsser sévère...)
      • [^] # Re: PCC concurrent de GCC ?

        Posté par . Évalué à 1.

        Et LLVM c'est pas du BSD la licence ? OpenBSD est en froid avec Apple pour preferer relancer un compilateur du siècle dernier ?

        Personnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ? Quand on voit l'énergie qu'il faut investir pour faire un compilo (optimisant et multi-plateforme, sinon c'est sûr c'est beaucoup plus simple)...
        • [^] # Re: PCC concurrent de GCC ?

          Posté par . Évalué à 3.

          Peut-être ne répond-il pas aux besoins des xBSD ? Moi ce qui m'enerve ce sont ces gens qui critiquent le choix de ne pas utiliser un outil quelconque parce que selon eux c'est du gachis que de passer du temps à redévelopper un autre outil qui semble faire la même chose ... C'est peut être bien plus qu'un problème de licence ...
          • [^] # Re: PCC concurrent de GCC ?

            Posté par . Évalué à 3.

            Sauf que dès que quelqu'un veut faire un nouveau noyau tout le monde va lui dire que c'est une mauvaise idée. Et en pratique ça en est une.
            Je pense serieusement que le niveau de complexité d'un compilateur est du niveau de la complexité d'un noyau. C'est pas n'importe quel outil...
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 2.

              Sauf que dès que quelqu'un veut faire un nouveau noyau tout le monde va lui dire que c'est une mauvaise idée. Et en pratique ça en est une.

              Non.

              Les raisons pur créer un nouveau noyau peuvent être multiples ... C'est comme si tu disais que forker un projet libre parce que ne convenant pas aux besoins est une auvaise idée ...

              Pour le noyau, l'intéret peut être que les projets exoistants ne répondent pas à un besoin précis, et que adapter l'existant au besoin coute autant, voir plus que redévelopper pour son propre besoin. L'intéet de développer un noyau peut être d'apprendre les concepts de base du développement de noyau pour oarticiper ensuite à un projet plus évolué (prendre en route un projet existant sans connaitre les principes fondamentaux sous jacents est quasi impossible).


              Et puis dans ce cas ils ne partent ps de zero, ils partent d'un outil qui était autrefois utilisé dans s les BSD .... donc qui est un minimum connu ...
              .
              • [^] # Re: PCC concurrent de GCC ?

                Posté par . Évalué à 2.

                Et puis dans ce cas ils ne partent ps de zero, ils partent d'un outil qui était autrefois utilisé dans s les BSD .... donc qui est un minimum connu ...

                (disclaimer: je fais de la recherche en compilation)
                Mouais, on peut toujours partir d'un jouet... Mais je persiste à penser que c'est généralement une perte de temps, il y a tellement d'optims à implementer... De plus PCC n'est pas vraiment un compilateur moderne (il aurait fallu commencer par faire du SSA et partir d'un vrai compilo cross-plateforme).

                C'est comme les gens qui font tous des VM ou des JIT dans leur coins alors qu'il y a tellement à faire...
        • [^] # Re: PCC concurrent de GCC ?

          Posté par (page perso) . Évalué à 6.

          le problème de llvm c'est qu'il est pour le moment incapable de se bootstrapper lui même (dev en C++ et pas de compilo C++ officiel - autre que llvm-g++ - pour le moment - CLANG n'est pas près de faire du C++), ce qui est quand même gênant pour les projets bsd. De plus LLVM est intéressant pour les ports et toutes les applis tierces, mais un "simple" et "petit" compilo C efficace est plus intéressant pour les projets BSD.

          Mais n'est craintes beaucoup de dev BSD sont intéressés par LLVM (en particulier chez FreeBSD).
        • [^] # Re: PCC concurrent de GCC ?

          Posté par . Évalué à 6.


          Personnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ?


          Oula, doucement...! De quelle gachis parles tu ?
          On t'a forcer à coder sur PCC ?

          Non, alors ne dis pas n'importe quoi. Les gars font ce qu'ils veulent, c'est du logiciel libre tu sais.
          • [^] # Re: PCC concurrent de GCC ?

            Posté par . Évalué à 1.

            Bien sûr que les gens font ce qu'ils veulent, mais c'est toujours triste de voir une communauté (des gens qui font un compilo sous licence BSD) divisée.
            • [^] # Re: PCC concurrent de GCC ?

              Posté par . Évalué à 4.

              Et quel gâchis KDE et Gnome !
              Ah tiens non, « ça a pas les mêmes objectifs ». Same here.

              La communauté de toute façon ne peut pas être uniforme et du même avis, il y a forcément des divisions, et de toute façon, la sélection naturelle fera le reste : si PCC devient une alternative viable pour compiler le basesys, il sera adopté, sinon GCC restera, il n'y a pas de mal. Au contraire, on peut lire le joyeux Theo qui trolle à fond et c'est rigolo. :-)
      • [^] # Re: PCC concurrent de GCC ?

        Posté par (page perso) . Évalué à -1.

        rien à voir avec OpenBSD ou Theo

        Interview de Theo au sujet de PCC (et GCC) :
        http://www.thejemreport.com/content/view/369/

        Extrait : « we hate large code, and buggy code that upstream does not maintain (...) gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts »

        Critique de GCC par Marc Espie du projet OpenBSD :
        http://undeadly.org/cgi?action=article&sid=2007091519520(...)

        Tu vois pas le rapport ?
        • [^] # Re: PCC concurrent de GCC ?

          Posté par . Évalué à 5.

          Quand Theo parle du noyau linux alors Theo est lié à linux ? C'est n'importe quoi.

          Le développement récent de PCC n'a rien à voir avec OpenBSD, mais est la volonté de ragge (à l'origine de NetBSD) qui en avait besoin.

          Au sein d'OpenBSD, un développeur (otto) s'est intéressé aux qualités du compilo, et après des discussions avec d'autres devs et Theo, il a été importé. Ca a également été le cas pour NetBSD.

          Ce que je trouve vraiment stupide, s'est d'affirmer des choses au sujet d'OpenBSD qui sont fausses. Un coup marketing d'OpenBSD ?? Tu crois que ragge a été payé par Theo pour relancer PCC et puis donne des pots de vins aux autres BSD pour travailler dessus ?? Arrêtons les blagues... PCC n'a pas attendu OpenBSD...
  • # Historique : y a quand même des fautes qui passent mal pour un journal

    Posté par . Évalué à 6.

    Depuis 2002, le code source à subit subi un gros nettoyage et plus de la moitié à été réécrit. Ainsi la version actuellement disponible est une modernisation de ce compilateur.

    Le compilateur GCC a introduit des extensions au language langage C
    Celle-là je la supporte pas ....
    • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

      Posté par (page perso) . Évalué à 2.

      Merci pour tes remarques. C'est corrigé.
    • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

      Posté par (page perso) . Évalué à 4.

      A propos de ces extensions, elles sont "standardisées" ou bien ce sont des extensions propriétaires ? Dans le 2ème cas, il y a vraiment sujet à troll : respect des standards, interopérabilité, toussa.
      • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

        Posté par . Évalué à 2.

        Ce ne sont pas des extensions standardisées ... d'ou le problème.

        Comme je disais plus haut, le fait d'utiliser des extnsions qu'apporte un outil n'est pas mal en soi, mais il faudrait toujours penser et développer en conséquence : distinguer les éléments qui utilisent ces extensions et développer son code pour que quelqu'un qui ne les utilise pas puisse facilement modifier le code en conséquence.
        • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

          Posté par (page perso) . Évalué à 2.

          le fait d'utiliser des extnsions qu'apporte un outil n'est pas mal en soi
          Si ces extensions ne sont pas indépendantes de l'outil et réutilisable dans un autre outil pour garder l'interopérabilité, pourquoi pas. Si par contre ce sont des extensions "propriétaires", c'est mal (TM). Surtout des extensions à un langage aussi important que le C.
          Bon j'ai pas vérifier mais je suppose que ces extensions sont facilement désactivables à la compilation, voir idéalement ne pas sont activées par défaut.
      • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

        Posté par (page perso) . Évalué à 10.

        merci de soulever ce qui me choque ...

        on rale pour le manque de respect des standards et les extensions propriétaire plus ou moins non documenté au niveau interoperabilité ( à ne pas confondre avec la doc utilisateur ), mais dès qu'il s'agit de la FSF et du projet GNU, ca ne dérange quasiment plus personne.

        donc le monopole du projet GNU qui tient au niveau des distribs essentiellement autour de la GNUlibc ... justifie à lui seul l'impositiion monopolistique d'un GNU/Linux. Et que l'on ne me sorte pas que tout repose sur du GNU dans linux ! sinon de la meme maniere, on devrait parler d'un GNU/OpenBSD dès qu'il y a besoin d'installer une partie du projet GNU pour faire fonctionner des trucs comme the Gimp, GNOME, OOo, ...

        Stop à la connerie, et admettons enfin que la situation du projet GNU est un monopole intellectuel qui techniquement ne repose que sur une dépendance à GNU make, GCC et la GNUlibc.

        le noyau linux est un des rares gros projet qui peut etre compiler sans GCC.
        Mais combien de projet utilise des extensions non standardisée et surtout sans spécification autre que du source et un bout de doc utilisateur ?

        Dans la même veine :
        Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?
        sachant que une GPL2 strict n'est pas compatible avec la GPL 3 strict ... cela ne dérange personne non plus.

        Donc la liberté c'est d'être compatible avec la FSF ? de respecter les choix de la FSF ? de penser comme la FSF ?

        drole de liberté qu'une liberté completement fermée et dependante du bon vouloir d'une organisation dirigée par un seul homme.
        • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

          Posté par . Évalué à 1.

          on rale pour le manque de respect des standards et les extensions propriétaire plus ou moins non documenté au niveau interoperabilité ( à ne pas confondre avec la doc utilisateur ), mais dès qu'il s'agit de la FSF et du projet GNU, ca ne dérange quasiment plus personne.
          Bienvenue dans la religion FSF ....

          Stop à la connerie, et admettons enfin que la situation du projet GNU est un monopole intellectuel qui techniquement ne repose que sur une dépendance à GNU make, GCC et la GNUlibc.

          C'est exact mais pas seumlement. Techniquement, GCC est loin d'être à la ramasse ... ce qui explique pourquoi il est également utilisé pour générer les divers BSD.


          Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?


          Si, les développeurs BSD par exemple ....

          Donc la liberté c'est d'être compatible avec la FSF ? de respecter les choix de la FSF ? de penser comme la FSF ?

          Bienvenue dans la religion FSF (bis).


          drole de liberté qu'une liberté completement fermée et dependante du bon vouloir d'une organisation dirigée par un seul homme.
          Note que comme beaucoup de religions, ce n'est pas le fondateur ou le noyau d'origine qui pose problème, mais une partie de ceux qui ensuite adhèrent au concept. En soi, le fait qu'ils pensent avoir raison et que les autres ont tort n'est pas gênant, par contre ce qui est gênant ce sont leurs pratiques pour imposer leur point de vue et refus d'admetttre que les autres peuvent penser différemment.
        • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

          Posté par (page perso) . Évalué à 6.

          Je te rejoins, d'autant plus que je vois plus haut que Stallman justifie des abérations techniques en invoquant des raisons politiques (garder un GCC monolithique pour éviter que le le backend soit réutilisable sans le frontend...) qui ne sont pas sans rappeler les débats sur la stabilité de l'interface du kernel (qui est justifiée puisque pas destinée à être interfacée avec "l'extérieur" mais critiquée parceque non utilisable dans de bonnes conditions par des briques tierces)

          On se dit qu'il y a vraiment une volonté d'enfermer tout le monde dans un même modèle. Ce modèle a beau offrir une vision philosophique intéressante, je trouve ca vraiment navrant de voir qu'elle conduit à mal concevoir des logiciels, voir à pratiquer une forme d'obfuscation (faire du monolithique pour faire chier), ce qui va complètement à l'encontre pour moi de la diffusion libre du savoir que veut pourtant promouvoir la FSF.

          En gros on applique ce qu'on critique : vérouillage de l'interopérabilité, extensions propriétaires, limiter la réutilisation et le pire, c'est qu'on les justifie avec la même philosophie qu'on utilise pour critiquer les autres modèles de logiciels.

          Heuresement, le modèle offre suffisament de libertés pour sortir de cette impasse. Vivement que certains utilisateurs "pragmatiques" forkent ces composants essentiels pour les rendre pérennes.
          • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

            Posté par (page perso) . Évalué à 7.

            >>> Stallman justifie des abérations techniques en invoquant des raisons politiques

            Y'a quand même un bel avantage technique qui est sorti de la position de Stallman : Apple a contribué au support d'Objective-C dans GCC alors que si il était possible d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain") que le support d'Objective-C serait resté purement dans le giron d'Apple.
            • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

              Posté par . Évalué à 3.

              Ou pas. Apple possède une grosse équipe de compilation qui contribue à LLVM (licence BSD). Il y a très peu de boites qui peuvent gérer un compilateur performant dans son intégralité la plupart prefèrent contribuer à de l'open source (LLVM, GCC, Open64, ...).
            • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

              Posté par (page perso) . Évalué à 2.

              que le support d'Objective-C serait resté purement dans le giron d'Apple.
              Et ? ca aurait été quoi le problème du moment que le résultat était sous GPL ? La FSF doit avoir le monopole sur le dev de GCC comme l'équipe du kernel doit avoir le monopole sur le dev des drivers ?
            • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

              Posté par . Évalué à 6.

              > Y'a quand même un bel avantage technique qui est sorti de la position de Stallman :
              > Apple a contribué au support d'Objective-C dans GCC alors que si il était possible
              > d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain")
              > que le support d'Objective-C serait resté purement dans le giron d'Apple.

              C'est marrant que prenne cet exemple, parce que Apple, qui est le principal contributeur de LLVM (qu'ils "donnent" gratuitement donc), a montré qu'on peux faire un compilateur modulaire, sous licence BSD, et auquel des boites peuvent contribuer sans radinerie mesquine. LLVM est le parfait contre-exemple de la théorie politique de GCC.
        • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

          Posté par . Évalué à 3.

          Nan mais sérieusement faut arrêter de psycoter là.

          Les extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.

          Alors si vous chercher juste un pretexte pour taper sur la FSF, cherchez ailleurs.
          • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

            Posté par (page perso) . Évalué à 1.

            Les extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.
            Mais on s'en fou que ce soit bien documenté et facile à trouver, le fait est que le code source qui les utilise ne respecte pas le standard C, et à ce titre aura peu de chance d'être compatible avec un autre compilateur : bref ca va à l'encontre de l'interopérabilité et ca créé une dépendance entre le code source et l'outil (le compilo en l'occurence).
            • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

              Posté par (page perso) . Évalué à 2.

              nan mais attends *personne* n'est obligé d'utiliser les extensions . Si tu tiens à faire du code 100% c99 et rien que c99 libre à toi. Le "probleme" que tu souleves concerne le codeur, et pas l'outil. Les extensions sont là parce qu'elles sont pratiques et que certaines personnes en ont l'utilité je vois vraiment pas quel est le probleme. Tous les compilos c/c++ ont leurs propres specificités quand on s'éloigne du noyau commun (le standard)
              • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                Posté par (page perso) . Évalué à 2.

                En plus on peu tout a fait utiliser les extention en restant compatible avec le reste

                #if defined __GNUC__
                /* utilisation des extentions
                #endif

                Et avec les #define qui vont bien on peut rendre tout ça assez joli.
                • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                  Posté par (page perso) . Évalué à 4.

                  Oui et avec les balises qui vont bien, on peu faire des extensions spécifiques à internet explorer dans sa page web…
                  • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                    Posté par (page perso) . Évalué à 2.

                    Où est le mal si ça peux enrichir l'expérience de l'utilisateur ?
                    (en considérant biensur que le site reste fonctionnel avec les autres navigateur)
                    • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                      Posté par (page perso) . Évalué à 2.

                      C'est vrai, si la compatibilité est toujours assuré. Mais les faits nous montre que c'est rarement le cas. Que ce soit parceque le dev est un grouik ou que son chef lui donne pas le temps de tout tester, et dit que tourner sur 97% des machines ça suffit.

                      Etpuis si il faut commencer à gérer les spécificités de chaque parseur, le code peut que devenir plus grouik et moins maintenable. C'est même tout l'intérêt d'une norme/d'un standard.
                    • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                      Posté par (page perso) . Évalué à 5.

                      en considérant biensur que le site reste fonctionnel avec les autres navigateur
                      Et les extensions elles servent à quoi si au final tu proposes une implémentation basée sur les standards ? Mon petit doigt me dit que la plupart des programmes utilisant les extensions proprios de GCC ne sont pas compatibles avec d'autres compilateurs parcqu'ils utilisent justement ces extensions pour se simplifier la vie, pas pour proposer une "meilleur expérience utilisateur".
                      • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                        Posté par . Évalué à 2.

                        Oh mon dieu des gens utilisent des extensions pour ce simplifier la vie, c'est grave !

                        Sans compter ceux qui utilisent des extensions parce que... ils n'ont pas le choix... AHHHHH MAIS QU'ELLE HORREUR !

                        Code un OS en C ISO 99 et reviens nous parler après.

                        Ou au minimum explique nous comment on fait de l'attribute packed (ou l'équivalent du compilateur XYZ, cette extension existe a peu près dans tous les compilateurs, et rien que pour ça elle mériterait d'être standardisé j'en conviens, mais en attendant on est bien obligé d'utiliser l'extension) dans un programme écrit en ISO C 99 strict ; on cast en char * et on fait les chargements non alignés soit-même avec du code de psychopathe ? super la maintenabilité. De plus la norme fait assez peu d'hypothèse sur la représentation des entiers ou des flottants, donc en fait ç'est quasi impossible sans recopier la mémoire pour l'aligner puis faire un chargement classique : super les performances.

                        De toute manière ça se voit que tu n'as pas lu la norme, vu qu'elle n'a rien contre les extensions cette fameuse norme -- et en fait elle est carrément formulée pour ne pas gêner les extensions et autres constructions non portables (parce que justement le C est principalement adapté pour coder des OS, ce qui est une activité qui consiste à écrire du code intrinsèquement non portable...).

                        Bref devant toutes ces considérations passionnantes, je résumerais ma pensée en disant : va faire sérieusement du C (pendant genre 1 an minimum à temps plein, mais 3/4 ans ça serait quand même mieux, et dans des domaines bas niveau parce que ça rime généralement plus à rien d'en faire dans un autre domaine en 2008) et reviens nous parler après.
        • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

          Posté par (page perso) . Évalué à 1.

          Mais combien de projet utilise des extensions non standardisée et surtout sans spécification autre que du source et un bout de doc utilisateur ?

          Ca, on est d'accord : il y a une norme C et C++, donc mettre par défaut les extensions GNU c'est de la grosse connerie. Je suis le premier à râler contre les projets GCC-only.

          Ca ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?

          Ca, beaucoup moins d'accord : faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme. Et je trouve quand même très pratique de pouvoir mélanger des projets grâce à cette "norme" de fait.

          Autant ta première affirmation tient du fait qu'il y a une norme à respecter, autant la deuxième va juste provoquer la dispersion dans le libre, ce dont le libre n'a absolument pas besoin.
          • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

            Posté par . Évalué à 0.

            Ca, beaucoup moins d'accord : faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme.

            La norme existe, c'est la Free Software Definition :
            http://www.gnu.org/philosophy/free-sw.html
            qui est équivalente dans les faits avec l'Open Source Definition :
            http://www.opensource.org/docs/definition.php
            • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

              Posté par (page perso) . Évalué à 2.

              Elles sont compatibles entre elles?

              Je sais qu'un programme à la norme ANSI C ou C++ compilera sur tout compilateur à la norme.

              Je sais aussi qu'un projet ayant une licence qui respecte les liens que tu as fourni ne sera pas forcement compatible avec une autre licence qui respecte aussi les liens que tu as fourni.
              Tu ne proposes donc pas une norme, puisque 2 licences respectant tes documents ne sont pas forcement compatibles.
              Tu ne proposes donc rien d'utile pour la compatibilité. "Être compatible GPL" propose à défaut un minimum de compatibilité entre les projets.
              • [^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour

                Posté par . Évalué à 2.

                Tu ne proposes donc pas une norme, puisque 2 licences respectant tes documents ne sont pas forcement compatibles.

                Je ne savais pas que "respecter une norme" impliquait que tout doit être compatible avec tout.
                J'imagine donc qu'il suffit que deux programmes soient écrits selon la norme ANSI C pour avoir des APIs compatibles l'une avec l'autre. C'est magique, ça simplifie la vie.

                Ce qui est ridicule dans ton commentaire plus haut, c'est quand tu dis « faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme » en faisant allusion à la GPL. Or la norme de la FSF pour les licences libres, ce n'est pas la GPL mais bien la Free Software Definition.
  • # Pourquoi remplacer GCC

    Posté par . Évalué à 4.

    Beaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer.

    Bonjour,

    Pourquoi remplacer GCC ?
    Je pose la question en toute innocence.
    J'ai vu qu'il y avait déjà des éléments de réponse dans les commentaires plus haut mais....
    Y-a-t'il plein de raisons que je ne soupçonne pas ?

    Innocement,
    blobmaster.
    • [^] # Re: Pourquoi remplacer GCC

      Posté par . Évalué à 5.

      Moi aussi je me pose cette question, car il y a TCC (http://bellard.org/tcc/) qui a l'air de tenir la route.
    • [^] # Re: Pourquoi remplacer GCC

      Posté par . Évalué à 3.

      J'y vois aussi un intérêt "stratégique":

      Les projets *BSD et GNU n'ont pas les mêmes buts ni les mêmes besoins et encore moins les mêmes contraintes.
      Les gens de GNU ont leur compilateurs qu'ils développent comme bon leur semble.

      Si les personnes des différents *BSD veulent une fonctionnalité en particuliers ils peuvent soit envoyer des patchs pour GCC, soit créer un fork, soit créer leur propre compilateur.

      La première solution pose un gros problème d'indépendance: Les patchs ne seront appliqués qu'au bon vouloir des mainteneurs de GCC qui passent déjà leur temps à travailler pour atteindre leurs objectifs.

      La création d'un forks pose pas mal de problèmes de maintenance, en particulier dans le cas d'une usine à gaz comme GCC. J'imagine que la licence en est un autre.

      Même si la dernière solution et la plus lourde en terme de moyen, c'est aussi la plus souple: Les projets *BSD auront leur propre compilateur qu'ils pourront faire évoluer selon leurs propres besoins. Tout simplement.
  • # Si ce n'était pas la licence...

    Posté par . Évalué à -5.

    L'initiative est certes intéressante, mais j'ai toujours du mal avec les appels à subvention pour des projets qui n'utilisent pas la GPL.
    Ce n'est pas un troll, mais l'idée que je puisse donner de l'argent à un projet qui pourrait être pillé légalement par une entreprise, me dérange...
    • [^] # Re: Si ce n'était pas la licence...

      Posté par . Évalué à 8.

      Les projets sous BSD ne sont PAS pillé, tout comme Linux n'est PAS un cancer.
      • [^] # Re: Si ce n'était pas la licence...

        Posté par . Évalué à 3.

        Avant de moinsser, peut-on m'expliquer comment on peut "piller" un projet BSD ? C'est comme le "vol" associé à la contrefaçon d'oeuvres numérisées et au téléchargement illégal ?
        • [^] # Re: Si ce n'était pas la licence...

          Posté par . Évalué à -5.

          Par "piller", j'entends redistribué sous forme binaire (parfois dans d'autres produits/projets), sans que les modifications apportées ne soient communiquées à la communauté.
          La licence BSD le permet, si je ne m'abuse.
          Maintenant j'aimerai que tu m'expliques avec quelle certitude tu peux affirmer que personne ne le fait...
          • [^] # Re: Si ce n'était pas la licence...

            Posté par . Évalué à 3.

            Et ce n'est pas justement parce qu'elle le permet que ce n'est pas du pillage ?
            • [^] # Re: Si ce n'était pas la licence...

              Posté par . Évalué à -1.

              C'est vrai pour celui qui choisit ce type de licence en effet.
              Celui qui choisit la licence BSD pour ses projets, fait à la fois un don à la communauté, mais également aux entreprises susceptibles de l'utiliser.
              Je ne suis simplement pas prêt à faire la même chose avec mon argent, c'est tout.
              • [^] # Re: Si ce n'était pas la licence...

                Posté par (page perso) . Évalué à 2.

                Je ne suis simplement pas prêt à faire la même chose avec mon argent, c'est tout.

                ca ne te permet pas de dire qu'une entreprise peut piller. Piller, c'est aller à l'encontre de la volonté de la personne pillée, ce qui n'est absolument pas le cas de la licence BSD.

                Alors vire ce mot de ton vocabulaire concernant la licence BSD, et respecte-la : on ne te demande pas de donner de l'argent obligatoirement pour un projet BSD ni d'aimer les projets BSD, mais de respecter ceux qui font un autre choix que le tiens.
                (sans compter que comme la BSD est libre! Le libre n'impose pas d'interdire le proprio)
                • [^] # Re: Si ce n'était pas la licence...

                  Posté par . Évalué à -1.

                  Si je donnais mon argent à un projet de ce type j'estimerais en effet que l'entreprise me pille MOI, car moi je ne partage pas la générosité de l'auteur envers les dites entreprises.
                  Donc j'ai parfaitement le droit d'utiliser ce vocabulaire, car c'est de mon éventuelle contribution dont il est question ici.
                  Mais où as tu vu que je ne respectais pas le choix de l'auteur ?!
                  L'auteur, tout comme moi, fait ce qu'il veut.
                  J'ai simplement parlé de mon choix à moi, et expliqué pourquoi je ne voulais pas donner MON argent.
                  • [^] # Re: Si ce n'était pas la licence...

                    Posté par . Évalué à 4.

                    Si je donnais mon argent à un projet de ce type j'estimerais en effet que l'entreprise me pille MOI, car moi je ne partage pas la générosité de l'auteur envers les dites entreprises.
                    Non ce ne serait pas du PILLAGE dans la mesure ou les conditions sont clairement définies au départ ...

                    Petite analogie : considères-tu qu'une banque te pille lorsque le taux d'intéret d'un prêt à taux variabla augmente, alors que lors de la souscription de ce prêt, il était clairement mentionné que c'était un prêt à taux variable ?

                    La c'est la même chose ....
                    • [^] # Re: Si ce n'était pas la licence...

                      Posté par . Évalué à -2.

                      Oui et c'est bien pour ça que je n'ai jamais fait ce type de prêt.
                      Va poser la question aux victimes des subprimes US, qui se sont retrouvées à la rue...
                      Tu pourras toujours leur expliqué "Oui mais pourtant c'était clairement mentionné..."

                      Blague à part l'analogie est foireuse, car ma démarche pour un don n'a absolument rien à voir avec l'obtention d'un prêt où je paye pour un service.
                      Quand je fais un don à un projet GPL je le fais pour la communauté, car je sais que l'utilisation du code sera équitable. Si je ne le fais pas pour un projet BSD, c'est parce que je sais que ça peut ne pas être le cas.
                      C'est comme faire un don à une ONG où tu saurais par avance qu'une partie des fonds pourraient être détournés.
                      Je respecte parfaitement la volonté de l'auteur, qui lui ne voit pas les choses de cette manière puisqu'il a choisit sciemment la licence en conséquence.
                      Ma générosité à moi s'arrête simplement à l'espace communautaire, lorsque la licence garantit l'équité.
                      • [^] # A propose des banques.

                        Posté par (page perso) . Évalué à 4.

                        Tu pourras toujours leur expliqué "Oui mais pourtant c'était clairement mentionné..."

                        C'est ce que je leur dirai, oui.
                        Ils ont joué avec le feu, ils prennent que ce qu'ils ont "acheté".

                        Certes, les banques ont manqué de leur devoir de conseil et ont prêté à n'importe qui, mais la faute est aussi aux gens qui se sont dit que ça monterai toujours, que consommer ce qu'on a pas gagné c'est bien, qui n'ont pas fait gaffe aux scénarios possibles.

                        J'ai un prêt à taux variable, et j'en suis content : je l'ai fait en connaissance de cause, je l'ai capé (+1%), j'ai subit l'augmentation mais elle était prévue dans mon budget (c'est écrit noir sur blanc dans le contrat : le taux suit l'Euribor), l'augmentation s'est arrêtée au capé, point. Je pouvais prendre un capé +2 moins cher, mais +2 me faisait peur (pour mon budget). La où d'autres auraient dit "c'est moins cher, je prend", j'ai regardé le risque (trop grand).

                        Il est un peu trop facile de mettre tout sur le dos des banques :
                        - Elles prêtent pas : des méchantes qui ne font pas confiance au consommateur
                        - Elles prêtent : des méchantes qui abusent des gens.
                        Dans tous les cas, l'accusation fait que le fautif sera toujours l'autre. Et ben non, il y a une grosse part de fautifs dans ceux qui ont pris l'emprunt.

                        Ma générosité à moi s'arrête simplement à l'espace communautaire, lorsque la licence garantit l'équité.

                        C'est mieux dit, et c'est totalement compréhensible. C'est ton droit.
                        Il n'y a pas besoin de traiter d'autres de noms qu'ils ne méritent pas pour donner ton opinion...
              • [^] # Re: Si ce n'était pas la licence...

                Posté par . Évalué à 5.

                Dans ce cas ce n'est pas un pillage. Ce qui est libre/BSD reste libre/BSD. Ce qui a été modifié par une boite proprio ... ben on s'en fout, et il est fort probable que si le soft sous licence BSD était sous GPL, il n'yu aurait pas eu de toute façon d'utilisation du soft et la boite aurait fait du full proprio ...
  • # Besoins d'OpenBSD

    Posté par . Évalué à 9.

    Note : le commentaire que je fais ici viens de mes observations et pas du tout de mes connaissances d'OpenBSD, quelqu'un de mieux renseigner aura peut-être des choses à rajouter ou corriger

    Je pense que la l'incompréhension du choix de PCC par l'équipe d'OpenBSD vient du fait que l'on ne prend pas en compte toutes les exigences du projet, je vais essayer de les synthétiser.

    L'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :

    - puisse compiler suffisamment rapidement et sans consommation excessive de mémoire pour compiler sur les machines peut puissantes. (voir à ce sujet http://www.onlamp.com/pub/a/bsd/2004/03/18/marc_espie.html la réponse à la question What is the plan for gcc3 introduction? (bas de page))

    - puisse compiler tout le système de base, dont le compilateur, ce qui signifie qu'il doit pouvoir se bootstraper

    - gère correctement l'intégralité des architectures cibles d'OpenBSD. Correctement signifie que la maintenance d'une architecture doit rester le plus simple possible et ne soit pas cassée sans arrêt au grès des commits.

    - Ce qui est très important est que les devs puissent facilement faire intégrer leurs modifications, ce qui ne semble pas être le cas sur gcc qui est essentiellement géré par les distributions commerciales Linux et par Apple dont les objectifs ne sont pas toujours conciliables avec ceux d'OpenBSD.

    - Sans oublier que les devs OpenBSD sont assez portés sur la sécurité et donc sur la simplicité ce qui, et je ne pense pas qu'on me donnera tord sur ce point, n'est pas la force de gcc.



    Étienne
    • [^] # Re: Besoins d'OpenBSD

      Posté par (page perso) . Évalué à 1.

      Pour les 3 premières raisons GCC convient parfaitement (cross-compilation pour les machines peu puissantes, compile tout le système et capable de bootstrap, gère toutes les archis cibles d'OpenBSD).
      En revanche les 2 dernières raisons sont parfaitement légitimes et je comprends pourquoi les devs d'OpenBSD cherchent une alternative à GCC
      • [^] # Re: Besoins d'OpenBSD

        Posté par . Évalué à 6.

        cross-compilation pour les machines peu puissantes

        Je te rappel que dans le post original, Etienne parlait du besoin de compiler rapidement. Tu considères que la vitesse d'un compilateur, c'est être capable de cross-compiler sur des machines puissantes quand sur l'archi cible c'est trop lent ?

        Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).

        J'ai chez moi une vieille Sun SparcClassic, qui met environ une semaine pour compiler le système complet. Je ne parle même pas de mon VAX... Si tu étais développeur, tu comprendrais que passer d'un compilo qui met une semaine pour compiler un OS à un autre qui met 5 fois moins de temps, c'est un TRES GROS avantage.

        Et puis quant à la portabilité, gcc l'est oui, mais c'est en comptant sur le fait qu'il soit catastrophique sur les archis autres que i386/amd64/PPC. Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ? Si c'était le cas, tu verrais que gcc est très loin d'être ce petit bijou que tu crois être...
        • [^] # Re: Besoins d'OpenBSD

          Posté par (page perso) . Évalué à 3.

          >>> Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).

          Effectivement c'est un bon argument et on comprends la nécessité d'un compilateur rapide. Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....mais bon c'est un choix. Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?

          >>> Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ?

          Excuse-moi de ne prendre en compte que les logiciels libres. Je sais c'est bizarre mais c'est comme ça.
          • [^] # Re: Besoins d'OpenBSD

            Posté par . Évalué à 3.

            Mais c'est pas un peu le principe du libre de pouvoir fonctionner sur ce que tu veux ?

            Et les gars qui le font tourner sur VAX le font souvent par plaisir.
          • [^] # Re: Besoins d'OpenBSD

            Posté par . Évalué à 5.

            Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....

            Ce que tu dis montre clairement que tu n'es pas développeur et que tes remarques sont sans aucun fondement.

            Pour toi un compilateur rapide produit du mauvais code ? C'est faux... PCC produit du bon code avec seulement très peu d'optimisations...

            Pour toi un bon binaire i386 voudrait dire un binaire vax lent et vice versa ? C'est complètement incohérent.

            Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?

            Non je ne le pense pas... par contre ce dont je suis sûr c'est que le fait de maintenir des archis lentes et complètement dépassées depuis des lustres comme le vax permet à OpenBSD de régulièrement découvrir des bugs qui ne seraient jamais remontés sur des plateformes rapides.
        • [^] # Re: Besoins d'OpenBSD

          Posté par . Évalué à 3.

          Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).

          Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?
          • [^] # Re: Besoins d'OpenBSD

            Posté par . Évalué à 2.

            Tout à fait, sur ce site même, il y a deux ans, miod l'expliquait déjà (le dernier post en bas de la page) :

            http://linuxfr.org/2006/11/07/21588.html
            • [^] # Re: Besoins d'OpenBSD

              Posté par . Évalué à 3.

              Je suis peut etre bete, mais j'ai rien trouvé sur ton lien montrant que les binaires soit différents.

              J'ai juste vu une allusion au fait que les binaire cross compilé n'avait pas été testé (et c'était révélé foireux)...
              • [^] # Re: Besoins d'OpenBSD

                Posté par (page perso) . Évalué à 2.

                Qu'est-ce qui t'empêche de compiler sur une machine puissante par cross-compilation, puis de tester sur la machine cible?

                C'est une excuse plus que foireuse la!

                PS : je ne pose aucune opinion sur le choix de PCC ou GCC ça pue ça gère pas les archis exotiques et ça rame, je me prononce juste sur l'excuse plus que foireuse qui peut être avancée pour "devoir" compiler sur une machine qui rame.
                • [^] # Re: Besoins d'OpenBSD

                  Posté par . Évalué à 2.

                  Justement! D'après ce que je comprends, la compilation native est un des tests pour vérifier que OpenBSD marche correctement sur une architecture cible.
                  Le seul moment ou OpenBSD utilise la cross compilation, c'est pour initier un nouveau port. Ensuite ils font de la compilation native.
                  • [^] # Re: Besoins d'OpenBSD

                    Posté par . Évalué à 3.

                    Tout programme non testé étant habituellement buggé, je comprends bien qu'un des tests soit la recompilation de l'OS en natif.

                    Mais c'est un test nécéssaire pour la validation pas pour le developpement ou la, tu auras le résultat bien plus rapidement en cross-compilant ce qui diminue notablement le nombre de compilation native nécéssaire..
          • [^] # Re: Besoins d'OpenBSD

            Posté par . Évalué à 9.

            > Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?

            De fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).

            L'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.

            C'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».

            Confronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).

            Une autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...
        • [^] # Re: Besoins d'OpenBSD

          Posté par . Évalué à 0.


          Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).

          Un binaire cross-compilé est moins "bon" qu'un binaire compilé nativement ?
          Tu m'apprends qqchose ... comment ça se fait ? tu aurais un lien ou une explication ?
        • [^] # Re: Besoins d'OpenBSD

          Posté par . Évalué à 4.

          [[Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).]]

          Hein? Et pourquoi les binaires générés par cross-compilation serait de qualité inférieure à ceux généré par compilation 'native'??

          On peut préférer compiler de manière native car c'est plus simple à mettre en oeuvre ok, mais la "qualité" des binaires..

          Soit dit en passant, ayant travaillé sur des projets C++ qui mettaient *plusieurs heures* a compiler (sans optimisation), je fais partie de ceux qui pensent que la vitesse de compilation est importante, oui.

          D'ailleur c'est un argument *pour* la cross-compilation pour les vieilles machines: entre un PC avec un ou plusieurs CPU multi-GHz avec des giga de RAM et un VAX, j'aurais tendance à penser que gcc sur le PC sera plus rapide à compiler que pcc sur le VAX..
    • [^] # Re: Besoins d'OpenBSD

      Posté par . Évalué à -1.

      L'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :

      Si l'objectif est de compiler le système de base, alors pourquoi s'embêter a ajouter une compatibilité gcc [1]. Je pense pas que le code de base soit du code GNU venant de Linux...
      Surtout que ca va pas trop dans le sens de la simplicité.


      [1]

      Amélioration de la compatibilité avec GCC

      Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC
      • [^] # Re: Besoins d'OpenBSD

        Posté par . Évalué à 8.

        Mais bordel vous lisez la news et les commentaires avant de poster des trucs idiots ?

        La team OpenBSD ne développe pas PCC ! OpenBSD est juste très intéressé par le produit afin de remplacer GCC.

        Donc la team PCC implémente si elle veut la compatibilité GCC.
  • # Qu'est-ce qui foire dans GCC ?

    Posté par (page perso) . Évalué à 4.

    N'étant pas du tout dans le secret des compilateurs, je me demandais si quelqu'un du métier pouvait résumer ce qui cloche dans GCC ?

    C'est souvent que j'en entends parler, souvent en mal, mais dans la pratique, j'en ai toujours été content pour l'usage que j'en ai fait et je sais que la plupart des logiciels libres que je chéris sont compilés avec ; donc, qu'est-ce qui cloche?

    Est-ce un problème de design, un problème d'implémentation, un problème de communauté qui implémente ? Est-ce que c'est un mauvais compromis efficacité/propreté ? Un mauvais compromis features/maintenance ?

    Désolé pour mon newbisme.
    • [^] # Re: Qu'est-ce qui foire dans GCC ?

      Posté par . Évalué à 10.

      Et bien d'après ce qui se dit dans cette news et les commentaires voici les principaux problèmes:
      - GCC n'est pas assez modulaire (séparation nette entre la partie de GCC qui lit le fichier source et crée un arbre du programme, entre la partie intermédiaire qui transforme cet arbre en un autre, entre la partie de GCC qui génère l'assembleur pour l'architecture cible), ce qui le rend difficile a maintenir.

      - critique des développeurs d'OpenBSD: GCC abandonne régulièrement des architectures (qu'OpenBSD supporte toujours) et GCC ne marche pas correctement sur les architectures moins courantes (qui ne sont pas x86, x86-64, itanium, power)

      - GCC est lent pour compiler, ce qui est gênant pour OpenBSD car ils compilent OpenBSD en continu et en natif sur de vieilles architectures / machines.

      - ce n'est pas faire un tort de dire des développeurs d'OpenBSD qu'ils sont des maniaques de la qualité (revues de codes permanentes, durcissement du système en intégrant le plus possible de technologies pour sécuriser le système) et ils disposent d'un compilateur GCC extrêmement modifié pour intégrer des technologies de sécurité, d'où l'intérêt pour eux de disposer d'un compilateur extrêmement simple dont ils peuvent facilement revoir le code (le code de GCC est énorme).

      - enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.
      • [^] # Re: Qu'est-ce qui foire dans GCC ?

        Posté par . Évalué à 2.

        - enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.


        Ils devraient réécrire OpenBSD en ADA ... :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.