Hello,
Je voulais avoir votre avis sur CMake...
J'utilisais QMake mais je me suis decidé de passer a CMake, plus generaliste je trouve.
Quel est votre avis et vos critiques sur d'outils de ce genre (automake, bjam etc ) ?
Merci a+
Hello,
Je voulais avoir votre avis sur CMake...
J'utilisais QMake mais je me suis decidé de passer a CMake, plus generaliste je trouve.
Quel est votre avis et vos critiques sur d'outils de ce genre (automake, bjam etc ) ?
Merci a+
Salut,
D'une façon générale je trouve tous ces outils trop intrusifs dans la mesure où ils sont la plupart du temps prévus pour être configurés en rajoutant des fichiers dans l'arborescence des sources, ou alors ils partent du principe que le fichier (central) de configuration se situe à la racine de l'arborescence du projet, etc..
MAT.
bjam, je ne connais pas trop, j'ai juste compilé dans la douleur Boost avec, don cun à priori négatif - monstrueusement -.
Autotools, c'est bien, avec libtool à côté, mais le pb est qu'il manque de plus en plus de fichiers dans les paquets de développement Fedora ou Debian - il manque par exemple les libgtk*.la sous Fedora Core, les libgsl.la et autres sous Ubuntu, ... donc utiliser libtool avec autotools, c'est la merde de plus en plus, donc je suis dégoûté de ce pseudo-standard qui part en live -.
CMake, j'utilise manitenant avec Qt4 - qmake est trop limitatif -, l'ajout d'option en ligne de commande est complexe mais ça se fait. Avantage monstrueux sur tous les autres, ça génère des fichiers Visual Studio si besoin est, ça passe sans pb sous Linux aussi, la mailing list est active, ...
Donc en ce moment, je suis pas mal pro-cmake - surtout que KDE l'utilise aussi maintenant -, il y a peut-être scons à surveiller.
J'ai lu pourquoi KDE avait switché à cmake, et qu'ils avaient d'abord choisi scons ... je vous laisse regarder l'histoire mais les gars de scons ils auraient pu faire un effort je pense, et les developpeurs de cmake ont été vraiment remarquables. Chapeau bas pour cmake, argument qui m'a poussé a philosophiquement l'essayer et l'adopter.Envoyé par Miles
On ne pourrait pas penser a un tutorial pour CMake ?
Miles: la chose qu'il manque dans tes tutoriaux sur Boost Thread & filesystem c'est quelques programmes complets, et pourquoi pas avec cmake ?
a+
Les prochains tutos que je ferai seront avec qmake, puis je pense passer officiellement à CMakeEnvoyé par epsilon68
Et dans ce projet que je prépare, j'espère pouvoir mettre un peu de tout - mais je pense plutôt utiliser QThread que Boost.Thread, trop immature
Un point négatif pour KDE à l'époque du choix scons/cmake, le gars a apparemment directement forké de scons sans s'impliquer dans le développement de la branche principale de scons.
Avantage de cmake, c'est qu'il a des outils pour charger énormément de bibliothèques externes.
En quoi exactement boost::thread est-il immature ?
Il n'a pas les semaphores mais ne peut-on pas les refaire a partir des mutexes.
mais je n'en suis plus tres sûr.
Sinon j'essaie de plus utiliser boostavec Qt pour l'UI
au sujet des thread, j'ai posé la question dans la discussion sur le COW,
je me demande si Qt se debrouille bien avec lîmplicit sharing et OpenMP ou encore boost.thread ?
Partager