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.
[^] # Re: Génial
Posté par Philippe F (site web personnel) . En réponse au journal scons 1.0. É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.