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 Gnurou (site web personnel) . En réponse à la dépêche SCons 1.0. É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