Mathieu Malaterre a écrit 172 commentaires

Grâce à une erreur 500 on peux lire que le serveur et un Debian avec Apache 2.2.22:

http://www.data.gouv.fr/fr/groups/sante-et-social

C'est GDCM: Grassroots DICOM et pas GDMC...

Je n'étais pas sur de pouvoir faire de la pub directement dans linuxfr. en tout cas merci pour les premiers commentaires.

Pourquoi la depeche est rempli de commentaires personnels ?

...
multi-plateforme, développée (et utilisée quotidiennement) dans
...

...
il y a déjà GIL et VIGRA enlarge your image qui utilisent ce type de conception ayant de nombreux adeptes (souvent assimilée à la seule bonne manière de faire du beau C++, ce qui est évidemment faux).
...

J'imagine que Adobe a payé des gens pour GIL et qu'il l'utilise en interne, parce que ca repond a un besoin.

Et effectivement ITK n'est meme pas cité dans l'article... sans doute parce que templaté: ce qui implique que c'est du "mauvais C++" CQFD.

Je comprends pas ? On est obligé de resté manger ? Je voulais juste passer rapidement.

La page ne permet que de specifier "Oui je reste manger".

Juste une question:
- ITK support les fichiers LSM
- BioImageXD support entre autre LSM

Il ne sont pas cité dans l'article et pourtant sont des references dans le domaines medicale (distribué sous license open source), qu'elles etaient les problemes avec ces toolkits ?

Le plus dur sous linux ca va etre les macro VB stockées dans les nouveau fichiers LSM :)

merci
ref:
http://itk.org
http://www.bioimagexd.net/

je lis ton commentaire, je ne comprends pas ton point.

... je ferme le commentaire directement <insert appropriate smiley>

Toi non plus tu ne suis pas bcp l'actualité. Donc grande nouvelle pour toi: Python 3.0 ne sera pas backward compatible ! et oui, c'est comme ca.
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.

Bon peut etre pas VMS, faut pas exagerer qd meme...

C'est pour une raison cross plateforme. Tu es censé faire une librarie (dynamique / statique) puis tu lies ton exe a cette lib: et hop une seule compilation. Je crois que le terme tres specific a autotools est: convenient library, qui n'as pas d'equivalence dans le monde Win32.
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...

Les commentaires sont clairement orientés pour le FUD.

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

Chouette le fork utilise CMake ! Je vais pouvoir compiler cdrkit avec borland c++ si je veux ;-P

Ah oui et une autre truc, les CFLAGS et CXXFLAGS sont passes aux compilateurs meme sur les Obj-C et Obj-C++. CMake considere vraiment les Obj-C et Obj-C++ respectivement comme des fichiers C et C++

Effectivement j'ai oublie de mentionner ca.
Mais encore une fois je ne pense pas que xlC soit supporte... ca ne marchera que si xlC reconnait les extensions .m et .mm

Ca marche bien dans le cas ou tu n'as qu'un arbre. Mais pour moi tu peux avoir une application qui depende d'une librarie et les deux CVS (ou bien un CVS et un SVN) ne peuvent pratiquement pas etre stable a la meme seconde. Je comprends que c'est un peu special, mais ca m'etonnait que personne n'ai eu le probleme.

Il n'y a pas de support direct de Obj-C/ Obj-C++, ca marche quand meme puisque gcc reconnait les extensions m et mm.
Tu peux essayer par example:

$ cat CMakeLists.txt
PROJECT(bla C)
ADD_EXECUTABLE(foo.m foo)

Et pour ObjC++

$ cat CMakeLists.txt
PROJECT(bla C++)
ADD_EXECUTABLE(foo.mm foo)

J'ai des images de regression dans un CVS et des tests (C++) dans un autre repository. Effectivement les deux sont dependant mais dans mon cas ils sont physiquement dans deux repository differents...

Ca serait plutot autotools+m4. Tu auras toujours besoin de ton bon vieux make. CMake ne fais que generer les Makefiles (avec dependences) pour toi. En gros:

$ autogen.sh
$ ./configure
$ make

devient:

$ cmake /chemin/des/sources
$ make

"En permanence" comment ca peux marcher. Genre je fais 2 commits (qui sont lies) mais je veux faire deux commentaires differents. Si tinderbox comment a recompiler juste apres le premier commit il va faire du bruit pour rien...

Bien vu ! Autant pour moi...

http://www.kdedevelopers.org/node/1948

no comment :)

Excellent, j'avais pas pu trouver pourquoi les dev avaient abandonne Scons. Merci!

...vraiment bonne remarque...
1. Le patent GIF est expire, il n'a jamais ete applique
2. CMake est BSD de toute facon

T'ecris toujours tes Makefiles a la main toi ?

CMake genere les Makefiles pour toi. Si tu developpe que sous Unix ya pas vraiment grand interet. Si tu fais du cross plateforme (Qt4, KDE), alors ca devient genial, car il fait les dependencies pour toi en C++, C, Fortran, Java et genere donc des Makefiles, NMakefiles, Visual Studio Projects, Borland Makefiles, Cygwin ...
Mais a la fin t'as toujours besoin de ton bon vieux make ( a noter que les Makefiles genere sont parallel, tu peux utiliser make -jx !)

Enfin pour n'importe qui qui fais un peu de prog, ca arrive ce genre d'incident. Ca me surprend d'ailleurs un peu vu qu'il y a un nightly et continuous testing de la compilation...

Au passage Scribus est aussi passer (non off) en CMake

[Success: Scribus 1.3.x cvs and CMake]
http://public.kitware.com/pipermail/cmake/2006-April/008847.(...)