Ipot ?

• [^]Re: Ipot ?

  Posté par EdM () le 26/08/2008 à 11:20. (lien). Évalué à 2.

  Et la suivante, "la version 1.0.1 est déjà prévue pour septembre".
  Scons est sûrement maintenu par un certains McFly roulant en delorean :-D

Pourquoi SCons ?

• [+] [^]Re: Pourquoi SCons ?

  Posté par Guid (page perso, ) le 26/08/2008 à 11:37. (lien). Évalué à -3.

  T'as lu le journal ?
  Tiens, cadeau http://fr.wikipedia.org/wiki/SCons

  • [^]Re: Pourquoi SCons ?

    Posté par Blackknight (Jabber id, page perso, ) le 26/08/2008 à 11:58. (lien). Évalué à 3.

    Mince, j'y avais pas pensé !!!
    C'est ton avis que je veux, pas une description de ce qu'est SCons.

• [^]Re: Pourquoi SCons ?

  Posté par Adrien PRé (page perso, ) le 26/08/2008 à 11:42. (lien). Évalué à 10.

  Je suis passé a Scons pour un projet utilisant 2 compilateurs différents et différents outils "maison" pour générer des fichier de code. (sans lancer de troll contre cmake)

  • Je compile notre logiciel deux fois plus vite sur un dual-core (lancement des compilateurs en parallèle)
  • En utilisant le cache, c'est encore plus rapide (16 secondes au lieu de 170 secondes au départ). Je ne crois pas que cmake ait cette fonctionnalité
  • C'est extrêmement facile d'ajouter le support de nouveaux compilateurs ou outils "maison"
  • scons a une vision globale des dépendances (y compris des fichiers générés par les scripts maison)
  • La documentation est facile d'accès (contrairement à cmake qui ne m'a pas convaincu sur ce point)
    Voila mes deux centimes.

  • [^]Re: Pourquoi SCons ?

    Posté par Mathieu Malaterre (page perso, ) le 26/08/2008 à 13:45. (lien). Évalué à 7.

    Les commentaires sont clairement orientés pour le FUD.
    
    Donc
    * oui cmake supporte la compilation parallele
    * oui cmake support distcc / cachegcc, et meme le precompiled header
    * oui cmake permet d'ajouter des modules externes tres facilement
    * oui cmake a une vision globales des toutes les dependances, et meme mieux permet -par ex- de construire une lib, en sautant le parcours de l'arbre de dependances (tres pratique).
    * la documentation est correct AMHA, mais c'est sans doute parce que j'utilise cmake depuis 1.2
    
    cmake est génial qd tu dois faire de la compilation sur win32, mais que tu n'as jamais ouvert Visual Studio de ta vie. Tu peux tout lancer en utilisant le couche d'abstraction: ctest et le mieux c'est integrer a cdash.
    
    Ca m'a permis de developer GDCM en trois fois rien de temps et ca compile avec MinGW, gcc sur debian, VS2005/VS2008, Free VS Toolkit et MacOSX. Et grace a cpack je fais mes release en un rien de temps.
    
    Ref:
    http://gdcm.sourceforge.net/
    
    et
    
    http://public.kitware.com/dashboard.php?name=gdcm

    • [^]Re: Pourquoi SCons ?

      Posté par JoeltheLion () le 26/08/2008 à 13:53. (lien). Évalué à 2.

      Tiens c'est marrant de croiser un ancien de creatis sur linuxfr... Ici on utilise presque tous CMake, et j'aimerais bien être de ton avis, mais il me semble qu'à moins d'y passer beaucoup de temps, cmake n'est pas très pratique:
      
      - il te recompile tous les fichiers objets pour chaque executable, d'après eux c'est pas un bug, c'est une feature, mais ça multiplie le temps de compilation par 5
      - Pourquoi avoir créé un langage pourri à partir de rien alors qu'il existe dix milles langages de script embedabbles super? (comme python pour scons)
      
      Le seul point où je suis vraiment d'accord avec toi, c'est le support visual studio: là c'est clair c'est génial de se retrouver comme par magie avec sa solution visual studio configurée aux petits onions.

      • [^]Re: Pourquoi SCons ?

        Posté par Mathieu Malaterre (page perso, ) le 26/08/2008 à 14:08. (lien). Évalué à 7.

        C'est pour une raison cross plateforme. Tu es censé faire une librarie (dynamique / statique) puis tu lies ton exe a cette lib: et hop une seule compilation. Je crois que le terme tres specific a autotools est: convenient library, qui n'as pas d'equivalence dans le monde Win32.
        Je comprends l'histoire du facteur 5, mais au moins precise: 'qd je prefere dupliquer mon code dans chaque exe plutot que de faire une jolie librarie, alors les temps de compilation sont multiplié par 5' :-P
        
        Sinon pour le language de cmake, encore une fois pour la meme raison. Je suis sur un system, AIX, SunOS, VMS, MacOSX, Win32, j'install cmake et hop c'est finis et ca marche. L'avantage c'est qu'ils sont backward compatible de cmake 2.6 a des vieux machins comme cmake 1.2. Je refuse d'installer python pour compiler mon application qui est ecrite en C++.
        
        J'attends de voir ce qui va se passer avec Python 3.0 qui n'est pas backward compatible. L'idée de faire tout et n'importe quoi dans un build system peut paraitre seduisante, mais pour moi ca va etre un beau bord** d'ici qlq année et ca ressemblera a des script automachin, ou il faudra exactement la bonne version de python pour que ca marche...

        • [^]Re: Pourquoi SCons ?

          Posté par Mathieu Malaterre (page perso, ) le 26/08/2008 à 14:15. (lien). Évalué à 2.

          Bon peut etre pas VMS, faut pas exagerer qd meme...

        • [^]Re: Pourquoi SCons ?

          Posté par Guillaume Knispel () le 26/08/2008 à 16:18. (lien). Évalué à 1.

          J'attends de voir ce qui va se passer avec Python 3.0 qui n'est pas backward compatible.
          
          Visiblement tu ne programmes pas en Python (ou alors trop peu).
          
          Comme pour tous les autres programmes Python de l'univers, soit le logiciel sera porté, soit il continuera à s'exécuter tout à fait normalement avec un joli petit Python 2 installé sur le même système, le plus probable étant qu'au début il restera en Python 2 et ptet que dans le futur il sera en Python 3.
          
          Je ne vois pas pourquoi chercher à anticiper des problèmes là où il n'y en aura pas...

          • [^]Re: Pourquoi SCons ?

            Posté par JAGUENAUD Anthony () le 26/08/2008 à 18:07. (lien). Évalué à 3.

            Ben, si un logiciel fonctionne bien, pourquoi le redévelloper, même en partie, juste parce que le language de script a changé de version majeure.
            Moi aussi j'y vois un problème. Je n'aimerais pas, que un programme dév en C89 ou K&R ne puisse pas être recompilé par un gcc récent parce qu'il supporte le C99.
            De même, je n'aimerais pas que mon vieux script bash ne fonctionne plus sous un bash récent.
            Imagine si je dois refaire mon environnement Un*x à chaque fois qu'une version de bash sort :-(

            --
            Je donne mon sang, et vous, que faites-vous pour sauver des vies ?
            http://www.dondusang.net/

            • [^]Re: Pourquoi SCons ?

              Posté par Octabrain () le 26/08/2008 à 19:41. (lien). Évalué à 3.

              Je ne trouve plus de liens qui en parlent en détails, mais les programmes python 2 pourront être passés en python 3000 grâce à un outil automatique (aucun besoin d'intervention humaine) : 2to3 (http://www.python.org/dev/peps/pep-3000/ )

              • [^]Re: Pourquoi SCons ?

                Posté par Antoine () le 31/08/2008 à 13:07. (lien). Évalué à 3.

                Bon, 2to3 ne permet pas d'effectuer toutes les modifications nécessaires automatiquement. Il traite seulement celles qui peuvent être raisonnablement automatisées sans risque d'erreur. De plus, le code produit ne sera pas du code Python 3.0 idiomatique. Exemple, là ou vous utilisiez l.keys() pour récupérer la liste des clés d'un dictionnaire, 2to3 le remplacera par list(l.keys()) car la méthode keys() dans Python 3.0 renvoie une vue (une sorte d'itérateur) plutôt qu'une liste. Cependant, dans beaucoup de cas la vue est suffisante et l'appel à list() ne sera pas nécessaire : vous pourrez l'enlever à la main après le passage de 2to3.
                
                De toute façon, il n'est pas nécessaire de redévelopper une application from scratch pour qu'elle fonctionne sous Python 3.0 (sauf peut-être si elle est très très mal écrite...). Le langage change sur des points importants, mais la syntaxe et les constructions sémantiques restent quasiment identiques. Le point le plus délicat est probablement la séparation rigoureuse entre chaînes 8 bits (bytes) et chaînes unicode (str), ce qui impose une spécification beaucoup plus claire de vos APIs (sous Python 2.x, il y a des conversions implicites des unes aux autres sous certaines conditions).

          • [+] [^]Re: Pourquoi SCons ?

            Posté par Mathieu Malaterre (page perso, ) le 26/08/2008 à 21:05. (lien). Évalué à -1.

            Toi non plus tu ne suis pas bcp l'actualité. Donc grande nouvelle pour toi: Python 3.0 ne sera pas backward compatible ! et oui, c'est comme ca.
            et meme si y'a des outils automatique pour convertir mes vieux scripts, dans le super-duper python 3000, je ne veux pas toucher des release legacy, ca doit marcher tel quel.
            
            Accessoirement l'argument backward compatible, n'est qu'accessoire, le plus important que je veux pas le meme probleme que les autobidules. Je veux cmake, c'est tout ! Si je compile un projet C++, je ne vois pas du tout pourquoi il faut que j'installe python, ca m'obligerais a avoir les meme requirement que python. CMake est ecris en c++ donc la seule obligation de la plateforme cible c'est d'avoir un compilateur C++ (certains diront que c'est deja trop), m'enfin c'est deja moindre.
            
            voili voulou.

    • [+] [^]Re: Pourquoi SCons ?

      Posté par Kerro () le 26/08/2008 à 18:41. (lien). Évalué à -2.

      Juste une réaction en dehors du sujet: tu cites GDCM, un logiciel dont je n'ai jamais entendu parlé, et tu indiques que tu l'as développé. Ah, je suis curieux, je m'empresse d'aller voir.
      
      Je tombe sur la description de GDCM:
      GDCM is an open source DICOM library. It is meant to deal with DICOM files (as specified in part 10 of the DICOM standard). It offers some compatibility with ACR-NEMA 1.0 & 2.0 files (raw files).
      
      ... me voilà bien avancé. Je ferme l'onglet directement :-)

      • [+] [^]Re: Pourquoi SCons ?

        Posté par Mathieu Malaterre (page perso, ) le 26/08/2008 à 21:06. (lien). Évalué à -1.

        je lis ton commentaire, je ne comprends pas ton point.
        
        ... je ferme le commentaire directement <insert appropriate smiley>

    • [^]Re: Pourquoi SCons ?

      Posté par Adrien PRé (page perso, ) le 26/08/2008 à 22:48. (lien). Évalué à 6.

      Je ne voulais pas faire de FUD.
      
      Par le support du cache, je voulais dire que scons avait un mécanisme interne pour gérer son propre cache (c'est multi-platforme et ça ne fonctionne pas que pour gcc)
      (il me semble que cachegcc ne fonctionne que avec gcc)
      
      Par rapport à la documentation, J'ai trouvé celle de scons plus facile d'accès lorsque j'ai eu à choisir entre scons et cmake.

• [^]Re: Pourquoi SCons ?

  Posté par Noj Han (Jabber id, page perso, ) le 26/08/2008 à 11:42. (lien). Évalué à 3.

  Les outils « moderne » de compilation (c'est à dire les autotools, scons, cmake, etc.) ont clairement beaucoup d'avantage sur la construction « à la main » d'un Makefile. En deux mots, tu lui dit juste de compiler, et il va te chercher ce qu'il faut tout seul pour te sortir ton executable, là où avec make il faut penser à tout avant. C'est en quelque sorte l'étape d'abstraction au dessus de make.
  
  Le vrai débat, est plus « lequel choisir » ? La plupart des gens semblent d'accord pour penser que les autotools sont assez peu amicaux avec l'utilisateur, donc le débat est plutôt « SCons ou CMake ? ».
  
  Pour le troll les arguments, voir ce fil récent, sur la même nouvelle :
  http://linuxfr.org/comments/957416.html#957416
  
  Sinon, on peut aussi lire les discussions autour du choix du projet KDE, qui a fait couler beaucoup d'encre.

  • [^]Re: Pourquoi SCons ?

    Posté par rewind () le 26/08/2008 à 12:58. (lien). Évalué à 3.

    > Sinon, on peut aussi lire les discussions autour du choix du projet KDE, qui a fait couler beaucoup d'encre.
    
    Ou lire l'article sur LWN qui résume un peu toute l'histoire :
    http://lwn.net/Articles/188693/

  • [^]Re: Pourquoi SCons ?

    Posté par TeXitoi (Jabber id, page perso, ) le 26/08/2008 à 13:49. (lien). Évalué à 2.

    Il y a aussi OMake : http://omake.metaprl.org/index.html
    
    OMake is a build system designed for scalability and portability. It uses a syntax similar to make utilities you may have used, but it features many additional enhancements.
    
    Bon, c'est vrai que c'est surtout un système de build adapté à OCaml. Il gère par défaut C, C++, OCaml, and LaTeX projects, or a mixture thereof.

• [^]Re: Pourquoi SCons ?

  Posté par stricaud () le 26/08/2008 à 11:44. (lien). Évalué à 6.

  Sans doute parce qu'il y en a qui doivent en avoir marre des touch et des tabulations.
  
  J'utilisais Scons pour éviter les fights avec autotools... pour finalement me retrouver avec les fights Scons ;-) par ex. avec les Makefiles il est intéressant de pouvoir compiler une unité (un sous répertoire) en tapant juste 'make' là où vous êtes. Avec Scons, du moins à l'époque où je l'utilisait, il fallait déclarer ces unités et revenir au répertoire racine du projet.
  
  Je suis maintenant passé à Cmake, car je m'en fout d'utiliser make ou autre chose, pourvu que je n'ai pas à galérer avec un système de build pour compiler les sources de mes projets. Et je ne suis plus jamais revenu à autre chose depuis (à part les projets qui ont autotools d'établi, j'ai pas envie de refaire le monde et perdre un temps phénoménal sur un système de build).
  
  Cela dit, Scons = autotools + make, écrit en python. C'est une bonne alternative, elle vaut le coup d'être regardée et utilisée.

• [^]Re: Pourquoi SCons ?

  Posté par Blackknight (Jabber id, page perso, ) le 26/08/2008 à 13:41. (lien). Évalué à 1.

  Merci pour vos réponses
  Dès que j'aurais le temps d'apprendre le Python, je regarderais tout ça de plus près.

• [^]Re: Pourquoi SCons ?

  Posté par Gnurou (page perso, ) le 26/08/2008 à 15:12. (lien). Évalué à 2.

  J'ai utilisé SCons dans deux projets, à chaque fois en remplacement d'un autre outil de construction.
  
  Dans le premier cas, c'était un ensemble de Makefiles. SCons a été génial en ce qu'il calculait lui-même les dépendances entre fichiers pour reconstruire le nécessaire. Avec l'ancien système, il y avait souvent des cibles qui n'étaient pas construites alors qu'elles auraient dû, causant des crashs en raison de l'incohérence qui s'en suivait et de longues séances de débug avant un furieux make clean.
  
  Autre bon point, certaines cibles étaient conditionnellement construites en fonction d'un ensemble de règles plutôt compliquées (changement d'une partie d'un certain fichier, etc.). Avant, on reconstruisait ces cibles à chaque fois pour être sûr de ne rien louper. Avec SCons, comme on dispose de tout Python, une dédiée et le problème est réglé.
  
  Le deuxième projet a été commencé il y a peu, et je l'avais démarré avec CMake. J'utilise Qt, et j'ai trouvé la gestion des diverses étapes de construction par CMake désastreuse. Qt nécessite de générer des fichiers spéciaux (les .moc) si certaines classes héritent de la classe Object de Qt. Avec CMake, il fallait tout préciser à la main. Avec SCons, la détection est automatique.
  
  À côté de ça, j'avais plutôt mal accroché à la syntaxe de CMake et à sa documentation dans laquelle je ne trouvais jamais ce que je cherchais. À ce niveau-là aussi j'ai trouvé SCons supérieur.
  
  Ah, et j'ai également apprécié la simplicité qu'il y a à faire une compilation croisée avec SCons.
  
  Je ne parlerais même pas des autotools qui n'ont pas volé leur surnom de autohell. :p

  • [^]Re: Pourquoi SCons ?

    Posté par Guid (page perso, ) le 26/08/2008 à 15:32. (lien). Évalué à 2.

    et j'ai trouvé la gestion des diverses étapes de construction par CMake désastreuse
    
    Ouais, c'est sûr que devoir rajouter une ligne pour chaque fichier mocable c'est pas terrible (Bon en réalité, y'a quand même moyen de s'en passer en utilisant QT4_AUTOMOC et ça demande de changer légèrement sa façon d'inclure les headers, regarde les projets dans KDE4, ils ajoutent pas chaque fichier mocable dans le CMakeLists.txt), mais sinon pour tout le reste je trouve que tu exagères; cmake pour compiler du Qt, c'est quand même le panard, ça roule quasiment tout seul.

Cons