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.
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 :)
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.
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.
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.
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:
"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...
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
# Le serveur est un debian !
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche data.gouv.fr v2. Évalué à 0.
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
[^] # Re: Information complémentaire sur GDMC
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal GDCM: Google Summer of Code 2011. Évalué à -2.
C'est GDCM: Grassroots DICOM et pas GDMC...
# pub ?
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal GDCM: Google Summer of Code 2011. Évalué à -1.
Je n'étais pas sur de pouvoir faire de la pub directement dans linuxfr. en tout cas merci pour les premiers commentaires.
# Commentaire personel
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CImg 1.3.0. Évalué à 1.
...
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.
# Non, je ne reste pas manger
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Jeudi du Libre le 15 janvier 2009 à Lyon. Évalué à 1.
La page ne permet que de specifier "Oui je reste manger".
# ITK / BioImageXD
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche pyLSM, un module python pour microscope LSM 510. Évalué à 2.
- 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/
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à -1.
... je ferme le commentaire directement <insert appropriate smiley>
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à -1.
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.
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à 2.
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à 7.
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...
[^] # Re: Pourquoi SCons ?
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à 7.
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
# CMake
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche cdrkit : Debian forke cdrtools. Évalué à 3.
[^] # Re: ObjC / Framework / MacOS X / GNUstep
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 2.
[^] # Re: ObjC / Framework / MacOS X / GNUstep
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 2.
Mais encore une fois je ne pense pas que xlC soit supporte... ca ne marchera que si xlC reconnait les extensions .m et .mm
[^] # Re: à la tinderbox
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 2.
[^] # Re: ObjC / Framework / MacOS X / GNUstep
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 3.
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)
[^] # Re: à la tinderbox
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 2.
[^] # Re: Question de base
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 3.
$ autogen.sh
$ ./configure
$ make
devient:
$ cmake /chemin/des/sources
$ make
[^] # Re: à la tinderbox
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 3.
[^] # Re: KDevelop
Posté par Mathieu Malaterre (site web personnel) . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 1.
[^] # Re: CMake sadness
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal CMake dans KDE. Évalué à 1.
no comment :)
[^] # Re: Explications de la part du developpeur de BKsys
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal CMake dans KDE. Évalué à 1.
[^] # Re: suxor
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal CMake dans KDE. Évalué à 2.
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 ?
[^] # Re: Pour ceux qui ne saisissent pas tout...
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal CMake dans KDE. Évalué à 2.
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 !)
[^] # Re: CMake sadness
Posté par Mathieu Malaterre (site web personnel) . En réponse au journal CMake dans KDE. Évalué à 1.
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.(...)