Fwd: Re: [Dcmlib] Integration gdcm dans ITK

Mon Apr 26 09:02:48 CEST 2004

Bonjour a tous,
je suis avec grand interet toutes les discussions au sujet de la gdcm, meme
si je ne donne pas suite par mail car cela tomber pour moi dans une periode
tres chargee.
Voici quelques elements de reponse en attendant qu'ils soient confirmes (ou
pas) par la direction.de creatis.

1) je suis pour que ITK puisse integrer Gdcm et que des personnes comme
Mathieu ou Luis contribue a son developpement.

2) Si cela passe par l'assouplissement de la license actuelle en une license
MIT, je suis egalement pour, sachant si j'ai bien compris que cela permet a
GDCM d'etre integre dans des produits commerciaux, et que de notre cote cela
ne nous en limite pas l'usage. Cela va dans un sens utile je pense a des
developpements de produits logiciels pour THERALYS comme pour CREATIS (on ne
sait jamais :-)

3) Mon avis de non informaticien (donc incompetent sur la question :-)
concernant Cmake, c'est que je suis egalement pour, son efficacite pour la
distribution de vtk sur plusieurs plateforme m'ayant convaincu. Si certains
veulent maintenir d'autres installeurs plus linux, ou plus win32, ils
peuvent toujours le faire, sachant que comme l'a dit Mathieu cela posera des
problemes de synchro ... Je pousserai de mon cote pour que cmake devienne la
reference.

4) Bien que cela fasse sourire Eric, il me semble indispensable qu'il y ait
un moderateur du developpement de gdcm pour en piloter les grandes
orientations (au cas ou il n'y ait pas consensus entre les developpeurs),
modifications d'arborescence, integration de formats ... , autoriser de
nouveaux developpeurs, en supprimer .... Je lance donc un appel a candidat.
Si ce moderateur n'etait pas de CREATIS, je souhaite qu'un des ingenieurs
CREATIS soit volontaire pour suive de tres pres gdcm ... Deuxieme appel.

En attendant des reponses concernant le 4), j'attend la validation de la
direction de creatis concernant les points 1) et 2).

A+
Hugues BENOIT-CATTIN
http://telecom.insa-lyon.fr/~yougz

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Jean-Pierre ROUX" <jean-pierre.roux at creatis.insa-lyon.fr>;
<dcmlib at creatis.insa-lyon.fr>
Cc: <luis.ibanez at kitware.com>
Sent: Sunday, April 25, 2004 4:03 AM
Subject: Re: Fwd: Re: [Dcmlib] Integration gdcm dans ITK

>
> > 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
>
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib