• # ...

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

    SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.

    "SCons is a fantastic build system, written in Python (1.5.2) that does lots of nice things like automated dependencies, cross platform operation, configuration, and other great stuff. I would have to say that it is probably going to be the best thing for building C/C++ projects in the near future."
    — Zed A. Shaw, Bombyx project lead
    • [^] # Re: ...

      Posté par . Évalué à 1.

      SCons is an Open Source software construction tool

      J'ai pris çà pour un acronyme récursif, au début, mais, en fait, non.
  • # Génial

    Posté par . Évalué à 9.

    C'est l'occasion de rappeler que scons c'est drôlement bien
    C'était également l'occasion de rappeler ce qu'était scons.
    Merci _alex de l'avoir fait.
    • [^] # Re: Génial

      Posté par . Évalué à 5.

      Et d'ailleurs, scons est tellement bien qu'il n'a finalement pas été choisi par le projet KDE (si je me souviens bien, c'était parce que les développeurs de scons n'étaient pas assez réactifs à leur goût et pas assez soucieux de leurs utilisateurs).

      Finalement, KDE a choisi CMake :
      http://www.cmake.org/HTML/index.html
      • [^] # Re: Génial

        Posté par . Évalué à 2.

        et au fait, ça sert à quoi ?
        • [^] # Re: Génial

          Posté par . Évalué à 3.

          Ca sert à vérifier que les dépendances sont présentes lors de la compilation d'un logiciel.
        • [^] # Re: Génial

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

          Ca sert aussi à gérer la compilation : lancer make comme il faut pour qu'il passe le moins de temps possible, gérer les options de compilation, faire la génération de lien correctement, faire des lib statiques ou dynamiques.

          Quand on survole, ça a l'air très simple mais quand on rentre dans les détails, c'est pas du tout du tout simple. Il y a des différences entre chaque compilateur, entre chaque plateforme. Il y a pleins de subtilités sur la façon de faire des libs dynamiques (installable, qui trouvent automatiquement leurs différences, ...).

          Au départ KDE avait choisi scons mais la lenteur et l'absence de flexibilité et la quantité de travail à faire pour faire compiler KDE avec on fait qu'il a été rejeté.

          A côté, CMake s'est imposé tranquillement mais surement. En tant que fan de python, ça me fait bizarre que ce soit un langage de compilation à base de Macros en majuscule qui marche mieux qu'un truc développé en python mais les faits sont là. Et les mecs de KDE font rarement des erreurs techniques.

          D'après Thomas Nagy qui a bossé sur scons pour KDE, les problèmes de scons tenaient vraiment à son architecture. Il a d'ailleurs écrit waf à la suite de ça: http://code.google.com/p/waf/

          KDE est vraiment très content avec CMake, il y a régulièrement des améliorations en terme de vitesse de compilation de rigueur, ou de correction de problèmes extrèmement subtils.

          Pour ma part, je l'utilise en j'en suis très content. Aussi simple à utiliser que qmake, mais mieux supporté et plus souple.

          La documentation pèche un peu parfois mais rien d'insurmontable. Je l'utilise principalement sous windows, avec mingw, pour faire des nightly builds de certains projets.
  • # scons pas bien

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

    C'est l'occasion de rappeler que scons c'est drôlement bien.

    J'ai entendu l'inverse : « scons c'est vachement pas bien ». J'utilise les autotools pour les vieux projets et CMake pour les nouveaux. Je trouve CMake plutôt simple et assez foncitonnel (pas besoin de coder des bouts en shell...).

    D'autres personnes pourraient donner leur avis sur scons ?
    • [^] # Re: scons pas bien

      Posté par . Évalué à 2.

      J'ai entendu parler de Waf en Python : http://code.google.com/p/waf/ Mais sans avoir eu beaucoup de retour pour savoir si c'était « bien » ou « pas bien ».
      • [^] # Re: scons pas bien

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

        La seule différence entre Scons et Waf (au niveau fonctionnalités / rapidité / facilité ) est minime mais si importante :
        - Scons doit être installé sur le système
        - Waf est uniquement fournis avec les sources et est indépendant de l'installation système (python uniquement)

        A mettre en relation avec [http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems], apparemment il est aussi possible de fournir Scons avec les sources.

        Waf mangez en, c'est bon
    • [^] # Re: scons pas bien

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

      à mon avis scons ne replace pas autoconf, mais surtout automake. C'est bien plus souple qu'un systeme de build basé sur des makefiles ou cmake puisque c'est du python. C'est ce que j'aime dans scons, on peut faire tout plein de trucs pendant la compilation, de la generation de fichiers, du parsage de xml, etc. C'est super puissant.

      Le cache (à la ccache, mais qui n'est pas restreint au c/c++) est aussi très pratique, mais cmake a sans doute une fonctionnalité similaire

      Par contre c'est un poil lent pour des gros projets (genre kde), et son extreme souplesse à pour conséquence que chacun fait ses sconscript à sa sauce, c'est pas toujours evident pour débuter
      • [^] # Re: scons pas bien

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

        Je ne saisi pas bien le rapport entre "bien plus souple" et "puisque c'est du python". Ca veut donc dire que les programmes en C sont très rigides ? Pas compris.

        Sinon avec make tu peux bien évidement faire tout plein de trucs pendant la compilation, de la generation de fichiers, du parsage de xml, etc. C'est super puissant. C'est justement fait spécialement pour ça. Pour générer des fichiers intermédiaires avant la compilation finale, pour récupérer des binaires ou des fichiers de configuration automatiquement avant de mouliner le tout.

        J'ai juste horreur de la syntaxe de Makefile. Heureusement que je suis seulement un programmeur du dimanche.
        • [^] # Re: scons pas bien

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

          plus souple dans le sens où le sconscript il est écrit dans un vrai langage élégant et turing-complet, contrairement à ceux de automake / cmake. Et si tu parses des fichiers xml pour modifier ton build avec des makefiles c'est avec des outils externes, alors qu'avec scons tu fais ça directement en python
          • [^] # Re: scons pas bien

            Posté par . Évalué à 1.

            t'es en train de m'expliquer que scons est tellement bien et souple toussa que tu as ressenti le besoin de mettre une partie de ta logique de compilation dans du XML que tu parses ???
    • [^] # Re: scons pas bien

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

      Il y a 2 ans on a utilisé SCons pour http://dev.openwengo.org/trac/openwengo/trac.fcgi/
      Au final c'etait lent, ie pas 'scallable' (plus le projet grossissait et plus c'etait effroyablement lent) et on a changé pour CMake qui n'a pas ce probleme.
      Bref entre SCons et CMake, je prefere largement ce dernier.
      En revanche, un avantage de SCons par rapport a CMake c'est les scripts qui sont en Python alors que CMake utilise une syntaxe maison
      • [^] # Re: scons pas bien

        Posté par . Évalué à 2.

        C'etais il ya 2 ans, peut etre le projet a t il fais des progrés sur ces points?
        J'hésite entre CMake et Scons et je dois avouer qu'avoir un systeme a base de python qui est un language que je maitrise me tente...
        • [^] # Re: scons pas bien

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

          En CMake, on n'écrit jamais de Python, on écrit dans un langage de script spécifique à CMake. Exemples :
          http://haypo.hachoir.org/hasard/file/tip/CMakeLists.txt
          http://haypo.hachoir.org/hasard/file/tip/lib/CMakeLists.txt

          Je maitrise pas du tout CMake, alors si ça se trouve on peut écrire ces deux fichiers bien plus joliment :) J'ai testé CMake sous Ubuntu Gutsy, FreeBSD7 et Windows (MinGW).
          • [^] # Re: scons pas bien

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

            Là où j'ai l'impression que Scons permet de faire tout et n'importe quoi, cmake s'est "simplement contenté" de factoriser des concepts communs à tous les systèmes de builds afin de les proposer dans un ensemble de variables/commandes, en saupoudrant le tout de notions de règles de dépendances, des règles de constructions. On peut bien sûr sortir du cadre classique de cmake et faire appels à des programmes externes mais globalement, ces utilisations spécifiques et les connaissances "métier" associées sont factorisées au sein de modules FindXXX.cmake qui permettent de ne pas réinventer la roue à chaque fois.
            Bref, en ce qui concerne Scons, trop de liberté pour un système de build, je ne suis pas convaincu que ce soit réellement un avantage.
            • [^] # Re: scons pas bien

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

              Je confirme.

              En partant du principe que "Scons est en python donc plus souple"; on se demande pourquoi utiliser Scons et pas plutôt juste python, ce serait "encore plus souple".

              Ce que je veux dire, c'est que pouvoir tout faire avec un système de compilation, c'est pas le but. Le but, c'est de pouvoir compiler ce qu'on veut, correctement, et si possible rapidement, sans galérer dans l'écriture des règles de compilation.

              Bien que fan de python, je dois reconnaitre que à l'usage, CMake est vraiment excellent. J'aurai préféré un autre système que des macros, et la gestion des chaines de caractères peut être un peu chiante, mais globalement, CMake fait son boulot très bien, pour tout un tas de plate-forme et de compilateur, avec des fichiers de configuration très simple à comprendre.

              Et dieu sait que c'est pas du tout facile. C'est facile de faire compiler un projet sur une plate-forme donnée avec un compilateur donné. Maintenant, gérer x systèmes de gestion de lib dynamiques, sur y plate-formes différentes avec z compilateurs, c'est vraiment un truc chiant.

              CMake s'en sort très bien, en gardant pour lui la complexité du truc et en exposant un langage de description des règles de compilation très simple. On peut même tirer partie des fonctionnalités spécifique de chaque plate-forme ou compilateur sans pour autant compromettre la généricité du CMakeLists.txt (l'équivalent du Makefile).
    • [^] # Re: scons pas bien

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

      J'aime bien SCons pour le coté python, qui permet de rajouter des fonctionnalités exotiques (je me suis par exemple amusé à le brancher sur Kdevelop pour faire des zip de release : http://nojhan.free.fr/article.php3?id_article=91 ).

      J'aime moins SCons sur la longueur, car il tend naturellement à produire des gros scripts baveux difficiles à maintenir... effet de bord de la souplesse, à mon avis.

      CMake à l'avantage d'être plus clair dans sa conception, mais moins souple à l'usage, avec une syntaxe peu ragoutante, là où SCons... bah, c'est du joli python, quoi.

      Je trouve également SCons un poil plus intuitif pour mon esprit tordu, mais CMake est plus carré pour des gros projets.

      Par exemple, faire un script qui télécharge le dernier SVN, le compile, en fait un zip pour la release et envoie le tout par FTP, il n'y à que sous SCons que c'est agréable.

      Au final, j'utilise CMake pour des gros projets avec pleins d'autres gens, et SCons pour des petits où je veux tout automatiser sans risquer de faire chier mes collègues.
      • [^] # Re: scons pas bien

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

        Par exemple, faire un script qui télécharge le dernier SVN, le compile, en fait un zip pour la release et envoie le tout par FTP, il n'y à que sous SCons que c'est agréable.

        Question sans doute con, mais qu'elle est la différence entre ce que tu fais et un autoconf qui lance le script qui telécharge, compile, fait un ZIP et envoie le tout sur FTP? (ça se fait à coup d'appel de .sh dans un configure.ac, rien de méchant, et je ne vois pas ce qu'on peut faire pour faire "mieux" en Python de ce côté.)

        La seule différence que je vois est que d'un côté c'est en scrip sh, de l'autre en Python, donc ex-aequo : faut apprendre une langue dans les deux cas (et je connais plus les script que Python, donc avantages scripts).

        Donc soit j'ai loupé un épisode, soit SCons n'apporte pas grand chose de nouveau à part pour les Python-addicts (que je ne suis pas, donc je devrais apprendre un nouveau langage) dans les arguments de souplesse avancés du moins.
        • [^] # Re: scons pas bien

          Posté par . Évalué à 1.

          La portabilité windows + macOS + linux etc...
          • [^] # Re: scons pas bien

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

            Les autotools le font aussi.
            (Windows par l'ajout d'un MinGW ou Cygwin certes. Pour MacOS X ca compile direct par ./configure && make)

            Pour Windows ou MacOS, ça serait plutôt les noms des compileur à citer : MS Visual Studio? Borland C++? Code Warrior? Si ça fait tout ça, je suis intéressé!
            • [^] # Re: scons pas bien

              Posté par . Évalué à 1.

              Et bien oui visual C++ 6, 7, 8 etc... pour ce qui est de windows icc pour intel et tout un tas de compilateur que je n'ai jamais vu...

              Et bien sur tout cela "out of the box". le script est identique mis à part les options de compilation qui dépendent du compilateur.
        • [^] # Re: scons pas bien

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

          Quand tu fais du autobouse faut quand même apprendre
          - le shell pour la partie script du configure.in
          - le language automake (cad la surcouche de make) pour les makefile.am
          - et cerise sur le gateau, le formidable et surpuissant GNU/m4 puisque les configure.in sont passés au préprocesseur

          Dès que tu fais des choses un peu sioux ça devient horriblement fragile, et quand libtool entre dans la danse t'es bon pour l'asile

          Et au final t'as un systeme de build très moyennement portable puisqu'il a une tonne de dépendances vers des outils unix (m4, sh, make, perl)
          • [^] # Re: scons pas bien

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

            et quand libtool entre dans la danse t'es bon pour l'asile

            Ah, ça me rassure un peu, je pensais être seul bon pour l'asile à cause de libtool :).

            Et au final t'as un systeme de build très moyennement portable puisqu'il a une tonne de dépendances vers des outils unix (m4, sh, make, perl)

            Euh... Je fais tourner Libtool et compagnie (surtout le ./configure qui en résulte) sur *nix, MacOS X, Cygwin et MinGW quand même... Et j'ai "juste" un Projet MSVC2008 en plus (et est-ce que SCons ou CMake saveint le créer à ma place? Je vois bien un truc Visual Studio dans la FAQ de CMake mais sans indiquer la version, rien dans SCons.)

            Est-ce que SCons ou CMake ofont la même chose à la fin (un "script" tout en un à diffuser)? Pour SCons, est-ce que j'ai besoin de Python installé? (non, parce que ça c'est rédhibitoire, Python n'est pas partout surtout pas sur des *nix exotiques et embarqués, et surtout je me vois mal imposer Python à mes utilisateurs, pour le moment ils ont juste à faire un ./configure && ./install sans se soucier d'une dépendance de l'installateur.). Les ./configure ça prend de la place aussi (je doit avoir 100 Ko de code source, et 400 Ko de ./configure, c'est lourd), SCons m'allège le bousin? (place d'un interpréteur Python inclu si il le faut obligatoirement).

            Vous l'aurez compris, je ne comprend pas encore tout dans ce que peux faire ou pas SCons ou CMake, je cherche à comprendre jusqu'ou ça peut remplacer ma chaine de compilation actuelle qui compile partout mais qui est assez lourde à gérer.
            • [^] # Re: scons pas bien

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

              scons sait generer des projets msvc mais je ne l'ai jamais utilisé donc je ne sais pas dans quelle mesure c'est utilisable.

              Et effectivement il faut un python d'installé pour executer le script, c'est vrai que c'est un peu lourd, mais bon c'est pas forcement pire qu'installer autoconf, automake, et libtool :)
              • [^] # Re: scons pas bien

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

                autoconf, automake, et libtool

                Euh... faut parler de choses qu'on connait! autoconf, automake, et libtool sont nécessaire sur le poste développeur uniquement. Rien de tout ça sur le poste cible.
                Et ce qui compte, c'est le poste cible... Car c'est lui qu'on ne maitrise pas. Ca ne m'embête pas du tout t'installer Python sur ma machine, ce qui m'embête est de devoir l'installer sur le poste cible (d'imposer comme condition à la personne d'installer Python juste pour mon soft si il ne l'a pas déjà installé.).

                Je reformule donc ma question : est-ce que Python est obligatoire sur le poste cible, ce qui en ferait une dépendance de plus de mon projet (ce que je "refuse"), ou seulement sur le poste développeur?
            • [^] # Re: scons pas bien

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

              cmake te génère ce que tu veux, tant que le générateur pour la platforme en question existe.
              Et actuellement, toutes les versions de Visual Studio sont supportées.
              A partir de tes fichiers CMakeLists.txt (qui sont les fichiers projets de cmake, ceux que tu écris amoureusement et avec soin), cmake te génère donc des solutions/Makefile/projets Kdevelop/etc
              Bon par contre, il ne faut pas être trop regardant sur les projets générés, les fichiers du projet sont par exemple des chemins absolus, mais ça n'a aucune espèce d'importance car les solutions/projets/Makefile sont considérés comme "jetables" et valable uniquement là où tu les as générés; tu ne peux pas filer ta solution/Makefile a quelqu'un et espérer qu'elle/il fonctionne chez lui, non, il doit lui aussi installer cmake et l'exécuter pour se générer son propre projet.
              Scons doit probablement faire la même chose que cmake.
              Avec cmake par contre, pas de python à installer.
              • [^] # Re: scons pas bien

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

                Merci pour les infos.

                Bon par contre, il ne faut pas être trop regardant sur les projets générés, les fichiers du projet sont par exemple des chemins absolus, mais ça n'a aucune espèce d'importance car les solutions/projets/Makefile sont considérés comme "jetables"

                Ah oui, mais non, ça a sont importance... Des développeurs n'ont pas forcement envie de se palucher l'install d'un truc dont ils se foutent royalement juste pour me faire un patch.

                C'est la où ça coince pour moi : les projets doivent être utilisables car je diffuse les fichiers projets, très utilisés.

                Bref, je crois que ça ne réponds pas (encore) à mon besoin, tant pis, je continuerai "à la mano". Encore merci pour les infos.

                Ah oui, une autre question : est-il encore obligatoire d'avoir un fichier CMake par répertoire source, et ce fichier dans le répertoire source en question? J'avais testé CMake il y a un moment, et ça m'avait bien rebuté cette obligation (pas question de polluer mon répertoire source avec des fichiers projets! ./src, c'est pour les sources.)
                • [^] # Re: scons pas bien

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

                  C'est la où ça coince pour moi : les projets doivent être utilisables car je diffuse les fichiers projets, très utilisés.

                  Oui, cmake est non seulement un générateur de projets mais il ne faut pas se leurrer, il est nécessaire à toute personne désirant bosser sérieusement sur le projet.
                  Pour moi, c'est très loin d'être rédhibitoire vu la simplicité extrême de l'installation et de l'utilisation de cmake. (sous windows, l'installeur se charge même d'inscrire ce qu'il faut dans les variables d'environnement (comme le PATH) à ta place)
                  De toute façon, c'est illogique et fastidieux de distribuer par exemple une solution MSVC générée à partir de cmake à un développeur, attendre un patch de sa part et ré-intégrer les éventuels nouveaux fichiers (ou optimisations) de cette solution dans le(s) CMakeLists.txt.
                  => Tout le monde bosse sur les CMakeLists.txt, les .sln/.vcproj ne sont plus jamais modifiés (en tout cas, pas de façon pérenne, juste pour des petits tests) mais juste utilisés, c'est ainsi que se conçoit l'utilisation de cmake. Et le traitement platform-specific doit être réalisé en amont dans les CMakeLists.txt grâce aux directives adéquates.
                  Pour le fichier CMakeLists.txt par répertoire source, bien sûr que non ce n'est pas nécessaire. La pratique qu'on trouve le plus souvent, c'est de créer un CMakeLists.txt par projet (une lib statique, dynamique, une application, un plugin, etc) et il est de toute façon toujours possible de référencer les sources de façon relative par rapport à la location du CMakeLists.txt.
                  Bref, vous l'avez compris, je suis fan :). Surtout que cmake se bonifie vraiment avec le temps, on trouve le support de plus en plus de bibliothèques tierces dans share/modules.
                  Le seul reproche que j'ai à lui faire, c'est sa documentation qui manque d'exemples et souvent d'explications.
  • # Sur CMake

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

    Attention à ne pas placer CMake sur le même niveau que scons, make & Co.

    CMake est un "Cross-Platform Makefile *Generator*."

    CMake se repose sur le système de build de la plateforme, il génère des makefiles, des projets Visual Studio, des projets XCode, etc... en fonction de la cible. Après, ce sont les outils natifs de build de la plateforme qui entrent en jeu.

    A la limite, CMake pourrait générer des scripts Scons...

    Ca a l'énorme avantage que vous pouvez ensuite utiliser les outils habituels de la plateforme - build, débogage, exécution pas à pas... - et que vous ne dépaysez pas trop les développeurs qui y sont habitués.

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

Suivre le flux des commentaires

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