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+
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
cmake vs automake vs bjam
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 à CMakeEt 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 ?
Il y a beaucoup de choses qui devraient exister ou qui ont existées pour Boost.Thread, comme les semaphores, mais aussi les readWriteMutex qui ont disparus. Par exemple aussi, tu supprimes un boost::thread, le thread continue à être exécuté...
Franchement, si tu utilises Qt, gardes les threads de Qt car la gestion correcte des signaux/slots multi-thread dépend du n° du thread, ce qui n'existe pas pour les autres bibliothèques.Sinon j'essaie de plus utiliser boost
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 ?
Ensuite, OpenMP pour du calcul //, de toute manière, c'est ponctuel, donc on peut s'arranger pour ne pas avoir d'implicit sharing, au pire.
Bon en general il ne faut jamais supprimer un thread, Java l'a meme retiré de la liste des methodes. Dans un cas concret tu as deja eu besoin d'en supprimer un ? Honnetement moi jamais...
Il y a eu des retours negatifs sur l'envoi de signaux entre threads.... avec du marshalling etc d'ailleurs dans ce forumHonnetement je ne sais plus quoi penser.
oui mais bon si tu utilises les collections de Qt, des QString etc ....
C'est pas tout le temps evident non ? A priori d'apres les reponses que j'ai eu dans la mailing list de Qt, comme ce sont des primitives systemes, cela ne changerait rien, mais attention a ne pas utiliser d'objet dependant de QThread dans OpenMP ou autre.
As-tu pu faire des tests sur l'implicit sharing des collections par rapport a la stl ? gains de performance ou pas ?
... je ne sais pas ce qui m'arrive, je defends de plus en plus boost en ce moment, l'argument qui me fait hesiter un max: et si Trolltech se fait racheter ou diminue son activité etc, il ne faut peut-etre pas mettre toutes ses billes dans le meme panier, ou pour un besoin de forte integration sur un systeme, il faudrait peut-etre un kernel metier independant de Qt. Bref je reviens sur Boost
je pense que c'est cyclique, ca va revenir.
Merci pour toutes ces remarques contructives
a+
L'avantage est qu'on a une bijection thread<->objet qui peut être judicieuse dans certains cas pour communiquer.
Je trouve intéressant de pouvoir poster des évènements entre threads de manière transparente, si on devait le faire soi-même, ça serait plus compliqué et moins efficace. Au pire, on peut toujours se connecter directement, sans fil, même entre threads. C'est plus modulaire, ça me plaît.Il y a eu des retours negatifs sur l'envoi de signaux entre threads.... avec du marshalling etc d'ailleurs dans ce forum
Là, je ne peux rien dire, faut dire que les compilos que j'utilise ne supportent pas OpenMP, mais si je devais te donner un conseil, fait une batterie de tests et vérifie la validité des résultats.
Des tests ont été effectués, et sur une utilisation standard, à savoir sans copie, ... la STL gagne, tout du moins celle de gcc, il y avait un article dans LinuxMag à ce sujet, mais sur Qt4.0 - Qt3.3 était plus mauvais, je crois -, donc avec 4.2, je ne sais pas.
Si Trolltech disparaissait - à mon avis, vu leur croissance, c'est pas de si tôt -, la fondation Qt récupère une licence BSD, donc aucun soucis avec KDE derrière.... je ne sais pas ce qui m'arrive, je defends de plus en plus boost en ce moment, l'argument qui me fait hesiter un max: et si Trolltech se fait racheter ou diminue son activité etc, il ne faut peut-etre pas mettre toutes ses billes dans le meme panier, ou pour un besoin de forte integration sur un systeme, il faudrait peut-etre un kernel metier independant de Qt. Bref je reviens sur Boost
je pense que c'est cyclique, ca va revenir.
Ensuite, il y a des outils de Qt que je n'utiliserai pas car Boost les propose en mieux, ce sont par exemple les pointeurs intelligents, si on prend Boost.Graph, ça n'existe même pas sous Qt, donc j'utiliserai les 2
Si cela peut aider, Noel Llopis avait testé divers systèmes de compilation
-> The Quest for the Perfect Build System
-> The Quest for the Perfect Build System (Part 2)
On pourrait aussi rajouter AAP de Bram Moolenaar (le mainteneur de vim) qui partage quelques propriétés avec scons ( python ; recompile sur des changements de signature, et non de date => lenteur). Je l'ai trouvé simple (je ne peux pas en dire autant de bjam), bien que peu pratique pour relinker du C++ (-> bug connu).
Et je n'ai vraiment pas accroché à ant, même avec le plugin CppTask. C'est une usine pas possible que je n'ai pas trouvé adaptée au C++.
PS: je n'ai pas l'habitude de détruire des threads non plus. Un join, oui.
Et je connais plus ACE que les autres systèmes. C'est un des frameworks (/ Le ?) le plus complet sur le sujet AMHA. Par contre, de temps en temps on y croise des trucs nécessaires fort peu communs comme des "delete this;" -- appelés dans les callbacks de fermeture/terminaison des tâches allouées dynamiquement, IIRC.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
tres interessant les liens, ils ne traitent cependant pas de cmake,
mais je me suis decidé de toutes facons
je vous donnerais du feedback
... bon faut avouer que c'est loin d'etre aussi simple que qmake !!!
et puis l'export vers VC++ 8 n'est pas bon il me genere un internal error
cmake mieux que qmake ? je ne sais pas faut encore que je creuse ...
juste pour ajouter que a l'heure actuelle, j'ai l'impression d'etre plus dans un trou que en haut de la vague ....
Ha non ce n'est pas cmake qui plante,
c'est bien VC++ avec boost
c'est un truc pourtant tout bete avec filesystem, timer et format
cmake, il n'en est pas question dans le blog car comme pour les autotools, c'est un toutil pour générer du code pour les outils "bas-niveau" tels que VS8, make, ...... bon faut avouer que c'est loin d'etre aussi simple que qmake !!!
et puis l'export vers VC++ 8 n'est pas bon il me genere un internal error
cmake mieux que qmake ? je ne sais pas faut encore que je creuse ...
cmake, le gros pb, c'est la qualité de la doc. Un exemple de fichier dans un sous-dossier de mes programmes/bibliothèques est attaché en pièce jointe.
ok probleme trouvé:
int main(int argc, char** argv) {
using boost::timer;
...
}
juste un truc ?
n'a-t-on pas le droit de mettre
using maclasse;
dans une fonction ?
parce que mince je trouvais ca pratique et ca marchait bien avec gcc
Répondre avec citation
Partager