La version 1.0 de SCons a été atteinte, le mardi 12 août 2008. Elle est fonctionnellement identique à la version 0.98.5, seules des mises à jour de documentation sont les nouveautés. Les API 1.0 resteront compatibles durant toute la vie de la série 1.x. La version 1.0.1 est déjà prévue pour septembre, incluant des corrections de bugs et améliorations de performances.
Les fichiers de configuration de SCons sont écrits en Python, ce qui offre une très grande souplesse et de nombreuses possibilités. Il analyse automatiquement des dépendances C/C++/Fortran. SCons permet de construire à partir de dépôts centraux de code source (SCCS, RCS, CVS, BitKeeper et Perforce) et/ou de cibles pré-construites, il utilise des signatures MD5 pour détecter des changements dans les fichiers et peut compiler en parallèle.
Ardour, Blender, VMware sont des exemples d'applications construites avec SCons. Les paquets sont disponibles sous forme de tarball, paquet zip, DEB et RPM, en source et binaire (et installeur Microsoft Windows).
Aller plus loin
- scons.org : site officiel (7 clics)
- SCons User Guide 1.0.0 (10 clics)
- Annonce (17 clics)
- ChangeLog (1 clic)
- Téléchargement (14 clics)
- Roadmap (14 clics)
# Ipot ?
Posté par J-C . Évalué à 1.
[^] # Re: Ipot ?
Posté par EdM . Évalué à 2.
Scons est sûrement maintenu par un certains McFly roulant en delorean :-D
# Pourquoi SCons ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
chers utilisateurs de SCons,
puis-je savoir pourquoi vous êtes passés à SCons ? Quels avantages en tirez-vous ?
En clair, pourquoi SCons plutôt que Make ?
[^] # Re: Pourquoi SCons ?
Posté par Guillaume Denry (site web personnel) . Évalué à -3.
Tiens, cadeau http://fr.wikipedia.org/wiki/SCons
[^] # Re: Pourquoi SCons ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
C'est ton avis que je veux, pas une description de ce qu'est SCons.
[^] # Re: Pourquoi SCons ?
Posté par bipbip . Évalué à 10.
Voila mes deux centimes.
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 2.
- 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 (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi SCons ?
Posté par Guillaume Knispel . Évalué à 1.
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 Anthony Jaguenaud . Évalué à 3.
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 :-(
[^] # Re: Pourquoi SCons ?
Posté par Octabrain . Évalué à 3.
[^] # Re: Pourquoi SCons ?
Posté par Antoine . Évalué à 3.
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 (site web personnel) . Évalué à -1.
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 . Évalué à -2.
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 (site web personnel) . Évalué à -1.
... je ferme le commentaire directement <insert appropriate smiley>
[^] # Re: Pourquoi SCons ?
Posté par bipbip . Évalué à 6.
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 nojhan (site web personnel, Mastodon) . Évalué à 3.
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 (Mastodon) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 6.
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 (site web personnel, Mastodon) . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 Guillaume Denry (site web personnel) . Évalué à 2.
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
Posté par Miguel Moquillon (site web personnel) . Évalué à 9.
Je voudrais ici rendre à César ce qui appartient à César.
SCons est une implémentation en Python de ce qu'est Cons, lui écrit en Perl.
Cons est celui qui a proposé ce mécanisme de build. SCons n'a fait que reprendre son approche mais en Python (probablement en l'enrichissant aussi).
Voilà, c'est tout.
Le site web de Cons : http://www.dsmit.com/cons/
Bonne journée ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.