Fwd: Re: [Dcmlib] Integration gdcm dans ITK

[Mathieu Malaterre]

> Bonsoir, les gdcmlibeux et les info-teamiens !
> 
> Il faudrait vraiment qu'on leur réponde, à Kitware !

Ca serait vraiment apprecié. Le mois de Mai approche à grand pas, donc l'affluence au labo va encore plus baisser. Est-ce qu'il n'y a que Jean-Pierre qui lie/réponds aux mails de la liste gdcm ? 

> Apparement, Luis Ibanez pense qu'on hésite à laisser le code de gdcm 
> dans le domaine public, alors que la volonté du Labo, c'était bien 
> qu'il *soit* dans le domaine public, non?

Souvent ce qu'on reproche à ce genre de collaboration c'est que l'argent des impots francais subventionne Creatis. Et finalement, Kitware société américaine va en profiter. Ce qu'il faut voir aussi, c'est que cette collaboration -et je l'espere vraiment- va permettre de s'assurer que le code de gdcm ne tombera pas dans les oubliettes comme beaucoup de code developpe dans les labos, donc finalement c'est le impots francais qui ne vont pas etre perdus. 

> Quant au problème du CMakeLists.txt, ce n'en est pas un, car il est 
> *déja* dans la distrib standard, et c'est Mathieu qui le tient à 
> jour, car personne ne s'en sert à creatis.
> Et, d'après la discussion informelle de la semaine dernière, Eric 
> voyait qq avantages à ce qu'on l'utilise (il est cross-platform), et 
> Fabrice était d'accord, à condition qu'on garde également les 
> auto-tools en local, pour Linux, c'est bien ça?

Pour moi, non le probleme des CMakeLists n'est pas resolu. Vu que le principe des autotools/CMakelists est de ne maintenir qu'UN seul systeme de compilation. Dans notre cas il y aura:
1. Les CMakeLists
2. Les Makefile.am
3. Les dsw (pour VC++)
4. Les workspaces .NET (je me souvient plus si le labo a la license .NET, mais de memoire oui).
5. Sans parler des gens qui veulent utiliser cygwin/mingw...

Concretement c'est impossible à maintenir, d'ou l'interet d'utiliser des tools du genre cmake/qmake/jam...

Toujours sur le meme sujet, il y a quelques problemes plus pragmatiques en ce moment:
1. Les Makefile.am / dsw a cause du dictionaire gdcm, n'ont pas de generation automatique du chemin d'access jusqu'a ce fichier. Pour contourner le probleme, un defaut a ete mis a ../Dicts
-> Avantage en mettant les librairies dans gdcm/lib et les binaires dans gdcm/bin on peut toujours retrouver ce fichier en utilisant cette astuce.
-> Inconvenients:
   - ca pollue les sources (des fichiers binaires se retrouvent dans l'arborescence des fichiers sources)  
   - comment faire si je veux compiler en gcc-2.95 et gcc-3.x ? Les librairies, ayant le meme nom, vont s'ecraser
Cela n'arriverait pas si le procede de compilation permettaient de placer les binaires dans le repertoires des binaires. On aurait ainsi, par ex:
- gdcm-src
- gdcm-2.95
- gdcm-3.x



Pour ceux qui auraient saute mon baratin, la conclusion est que je vais changer -maintenant- les CMakeLists.txt pour qu'ils placent les exe et les lib dans l'arborescence binaires. Ce qui m'amene a la conclusion suivant: je vais briser synchronisation CMakeLists/Makefile.am actuelle.

Je n'ai ni les connaissances, ni les ressources, pour propager mes modifications des fichiers CMakeLists dans les Makefile.am et les dsw actuelles, donc -au risque de me repeter- avoir deux -voire trois- build system va etre extremement difficile à maintenir. Commentaires/Suggestions/Reponses _vraiment_ apprecies.

Maintenant, je vois se profiler à l'horizon, l'argument: on n'a pas le controle sur les CMakeLists. Vu que c'est nous qui faisont la proposition, c'est a notre charge de maintenir ces fichiers. Donc tres prochainement, ils contiendront tous les parametres necessaires a la cross-compilations, aux tests automatises, passage par valgrind... Dans le pire des cas, si vous aviez a faire des mofications de votre cote, les CMakeLists -corriger moi si je me trompe- son suffisement facile a lire pour corriger des typos, des parametres perso, des ajouts de nouveaux fichiers source/tests/exemples.


Sinon toujours au chapitre des CMakeLists et pour montrer que ce n'est pas que du vent. En operant quelques modifications aux fichiers CMakeLists.txt actuels Luis a pu mettre en place un systeme de tests automatises sur sa machine:

http://public.kitware.com/Public/Sites/starsend.kitware/GDCM-Linux-g++-3.3/20040424-1859-Experimental/Test.html

Cela requiert l'addition de fichier specifique, que je vais  ajouter au CVS. En cas de desacord je les enleverais.

Merci de votre attention pour ceux qui sont arrives jusqu'ici,
Mathieu