La version 1.0.0 de scons http://www.scons.org/ est officiellement sortie le 12 août dernier. C'est l'occasion de rappeler que scons c'est drôlement bien.
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
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).
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.
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 ?
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 ».
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)
à 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
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.
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
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 ???
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
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...
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).
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.
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).
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.
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.
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é!
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)
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.
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 :)
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?
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.
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.)
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.
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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# ...
Posté par _alex . Évalué à 10.
"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 Obsidian . Évalué à 1.
J'ai pris çà pour un acronyme récursif, au début, mais, en fait, non.
# Génial
Posté par dab . Évalué à 9.
C'était également l'occasion de rappeler ce qu'était scons.
Merci _alex de l'avoir fait.
[^] # Re: Génial
Posté par Frédéric COIFFIER . Évalué à 5.
Finalement, KDE a choisi CMake :
http://www.cmake.org/HTML/index.html
[^] # Re: Génial
Posté par Rémi baudruche . Évalué à 2.
[^] # Re: Génial
Posté par YvanLeTerrible . Évalué à 3.
[^] # Re: Génial
Posté par Philippe F (site web personnel) . Évalué à 4.
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 Victor STINNER (site web personnel) . Évalué à 4.
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 zebob . Évalué à 2.
[^] # Re: scons pas bien
Posté par Clément David (site web personnel) . Évalué à 1.
- 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 Troy McClure (site web personnel) . Évalué à 2.
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 Kerro . Évalué à 4.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: scons pas bien
Posté par moi1392 . Évalué à 1.
[^] # Re: scons pas bien
Posté par tanguy_k (site web personnel) . Évalué à 5.
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 Dufréchou Laurent . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 2.
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 Guillaume Denry (site web personnel) . Évalué à 4.
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 Philippe F (site web personnel) . Évalué à 3.
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 nojhan (site web personnel, Mastodon) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 1.
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 Frédéric-Emmanuel Picca . Évalué à 1.
[^] # Re: scons pas bien
Posté par Zenitram (site web personnel) . Évalué à 1.
(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 Frédéric-Emmanuel Picca . Évalué à 1.
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 Troy McClure (site web personnel) . Évalué à 4.
- 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 Zenitram (site web personnel) . Évalué à 2.
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 Troy McClure (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 2.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: scons pas bien
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 2.
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 Guillaume Denry (site web personnel) . Évalué à 4.
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 lolop (site web personnel) . Évalué à 5.
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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.