[Dcmlib] WARNING: Ne pas mettre a jour le cvs de gdcm

[Mathieu Malaterre]

..avant d'avoir lu ce mail.

Bonjour,

   Il y a eu quelques changements dans le cvs de gdcm, donc je voulais mettre au courant. Pour les decideurs pressés qui n'ont pas le temps de lire ce mail, les Makefile.am / et dsw ne construisent plus les tests de gdcm/Test.

   Maintenant la version plus longue:
1. Effectivement afin de mettre en place les tests automatisées, j'ai du casse les tests actuels. En gros les fichiers C++ ne contiennent plus de fonctions 'main', mais sont enregistrer aupres d'un driver qui se charge de les executer. Ca simplifie beaucoup de code et evite de reinventer la roue pour chaque tests. 

2. Maintenant pour le cas pratique: 'Alors comment je fais pour executer mes tests si c'est plus des vrais executables?'
...la reponse courte est il faut utilise cmake
Le reponse longue est:
- Aller dans /tmp (par ex)
- Mettre a jour gdcm (cvs up)
- creer un repertoire /tmp/gdcmbin
- aller dans ce repertoire
- taper ccmake /tmp/gdcm (ou ccmake ../gdcm ca revient au meme)
- selon les options (python, vtk ...) il faut specifier quelques chemins:
  1. GDCM_DATA_ROOT, c'est le chemin jusqu'aux images dicom
  (chez moi: /home/mathieu/Creatis/gdcmData/ )
  2. CMAKE_INSTALL_PREFIX, c'est l'equivalent du '--prefix' des configures. Chez moi: '/opt/gdcm', j'aime pas mettre des biblioteques de dvpt dans /usr ou /usr/local
  3. CMAKE_BUILD_TYPE, en gros c'est soit Debug (-g est passe en parametre) soit Release (-O3) est passe en parametre. Chez moi: Debug (!!).
  4. si vous voulez VTK, il faut specifier le chemin jusqu'a VTK. Chez moi: /home/mathieu/Kitware/VTKbin

Ca prends entre 1 à 2 minutes à configurer mais une fois fait plus besoin de le changer. Pour les accros de la touche  'tab' sachez que l'autocompletion marche. Et pour ceux qui n'aiment pas les 'GUI', vous pouvez toujours utiliser cmake + vi/emacs/winword.exe pour modifier le fichier CMakeLists.txt.

- Taper 'c' pour configurer
- Taper 'g' pour generer
- make pour compiler
- make install pour installer (optionel)
Attention si vous sautez l'etape d'installation vous aurez besoin de definir une variable d'environement GDCM_DICT_PATH jusqu'a dicomV3.dic. Sinon l'etape 'make install' hardcode dans les exe un chemin par default calculer par:

   CMAKE_INSTALL_PREFIX + /share/dicomV3.dic

(donc il faut specifier CMAKE_INSTALL_PREFIX *AVANT* la compilation.)

Voila maintenant dans le repertoire /tmp/gdcm/bin il n'y a plus que gdcmTests.exe. Vous pouvez l'executer de plusieurs facons:
1. Directement et il vous propose d'acceder aux tests pas numeros
2. gdcmTests + nom_du_test, par ex: 
$gdcmTests bug1
3. Le fin du fin: se placer dans le repertoire /tmp/gdcmbin, et taper 'ctest'. Le programme va cherché tous les tests possibles (selon la config avec vtk, python...) et essayer des les executer. Il fait le calcul du temps d'execution reporte si tout c'est bien passé, et bientot fera une difference entre l'image lue et l'image telle qu'il doit la lire. Par ex sur VTK on a:

http://www.vtk.org/Testing/Sites/shannara.kitwarein/SunOS-CC/20040424-0300-Nightly/Results/__Rendering_Testing_Tcl_volTM2DRotateClip-image.html

Particulierment interressant quand on modifie quelques lignes de code dans gdcm. Il suffit de taper ctest et tous les tests vont s'executer, si tout se passe bien on peut commiter. Sinon on a acces immediatement au test qui flanche.

Vous etes toujours la ? Maintenant le phase ultime, l'envoi des resultats de tests sur la machine public de kitware:

  http://public.kitware.com/dashboard.php?name=public

Toujours dans /tmp/gdcmbin taper:

    ctest -D Experimental

Il y a deja eu quelques essais ce WE entre Luis et moi:
 http://public.kitware.com/Public/Dashboard/20040425-0100-Nightly/Dashboard.html

Non ce n'est pas le tableau de bord du concorde, c'est meme assez simple quand on a pris l'habitude de le lire, et ca fais gagner enormement de temps, vu que les tests sont executes de nuit, il suffit le matin de regarder par architecture (OS) qui a flanché pendant la nuit.
En gros pour lire le tableau: ligne par ligne c'est une architecture differente. Quand il y a une case rouge, c'est mauvais signe (seg fault ou probleme grave), quand c'est orange (l'image dicom a ete mal lu mais l'execution s'est bien passee). si c'est vert c'est parfait.

Voila, merci de m'envoyer vos commentaires, et comme precisé dans les logs de mes commits. Si le changements des Tests est trop difficile a gerer de votre cote, on peut essayer de trouver une solution (a mi-chemin entre l'automatisation et 'a la mano').

Mathieu

Appendice: Utilisation + pousse de ctest

I. Pour l'instant il n'y qu'un nombre limite de tests, mais dans l'absolu on cherche souvent a n'executer qu'un seul test. Plusieurs solutions:
1. lancer gdcmTest / attendre / taper le numero
2. on a une bonnse memoire: on tape directement gdcmTests nom_du_test
3. On a la memoire qui flanche on utilise par ex:
ctest -R make 
(ctest va chercher tous les noms de tests qui contiennent l'expression 'make', c'est une expression reguliere donc on peut compliquer la sauce).


II. Pour plus de details lors de l'execution du test:
ctest -R make -V
(avec V pour verbose / verbeux)

III. Pour les utilisateurs de zsh, vous pouvez gagnez quelques millisecondes. Plutot que d'utiliser ctest:
  -> make + <TAB> propose tout un choix notement 'test' , Experimental...
Donc :
ctest                 = make test
ctest -D Experimental = make Experimental
...

Sinon evidement je vous renvoi au man / info habituel pour plus d'info sur cmake/ctest.

La page de telechargement:
http://cmake.org
http://cmake.org/HTML/Download.html

un grand merci a Luis pour avoir mis en place les tests sur sa machine et m'envoyé le patch pour que je l'applique chez moi.