[Dcmlib] unification libjpeg... finis !

[Eric Boix]

	Bonjour Mathieu,

Congrats pour l'unification des libjpeg !

Quoting Mathieu Malaterre <mathieu.malaterre at kitware.com>:
> Il y'a juste deux include pas tres propre dans gdcmJpeg / gdcmJpeg12
> vu que je specifie un full path jusqu'a mon header jpeg...
Bah, ce que tu considere comme pas tres propre est surement mieux que
certains morceaux des internals...

> Au passage est-ce que je peux renommer gdcmJpeg.cxx/h en gdcmJpeg8.cxx/h
> c'est pour etre consistent(*)
Ben oui, n'he'site pas. Surtout si c'est pour la consistencY ;)

> J'ai pas repondu pour le wrapping python, mais moi aussi je m'y attaque
> cette semaine.
Deux choses:

 - La partie setup.py est sans doute la plus complique'e. (a ce sujet
   j'ai deplace' des .py de GDCMHOME dans gdcmPython/SetupOldies, si
   jamais tu les cherches). Il nous (Benoit et moi) a fallu faire des
   modules pour patcher distutils pour gerer proprement Swig et
   les wrappeurs VTK. C'est pas si trivial que cela. 
   L'autre difficulte' est de gerer l'equivalent du gdcmConfigure.h...
   Ajoute a cela le MANIFEST.in qui doit fonctionner a tout les stages
   (build, package source, package binary) et le tableau est complet.
   Bref, ne t'acharne pas la dessus plus que de raison.

 - La partie wrapping pure (en gros gdcmPython/gdcm.i et __init__.py)
   est un peu out of date. Pour gdcm.i beaucoup de typemap me semblent
   outrageusement redondants (et pour certains sans doute inutiles).
   De plus, un des principaux typemap (" %typemap(out) TagDocEntryHT &",
   pour ne pas le nommer), n'est plus du tout a jour, puisque desormais
   le resulat du parsing d'un gdcmHeader est un arbre et non plus un 
   dictionnaire a plat. Il faut donc ecrire la recursion, OU MIEUX utiliser
   le dictionnaire temporaire engendr'e par gdcmHeader::BuildFlatHashTable().
   J'avais ecrit cette methode en pensant precisement aux wrappeurs python.
   Re-bref, y'a du taf au dela du replatrage.

Bref, tout cela pour dire que si quelque chose pete:
 1/ mets le de cote
 2/ ne perds pas ton temps
 3/ demande nous

> Le namespace gdcm ca sera qu'apres le wrapping python + setup.py.
Effectivement, cela me semble apres dans l'ordre des priorite's. Mais
ce sont deux taches orthogonales, donc vive le parallelisme...

> Alors pas de feedback sur les problemes big endian ?
J'ai pas eu le temps de regarder cela. J'ai c,a sous le coude mais je veux
finir le gros chantier des PixelConvert avant tout chose.

>Sinon makedicomDir casse sur mon build cygwin, si quelqu'un a des suggestions.
Dis tu veux pas nous faire (en dix minutes) une ch'tite page oueb qui
concentre les pointeurs vers les dashboard et les tests. Je la mettrai
sur le site oueb de gdcm. Mon probleme chronique est en particulier que
l'URL change constamment (normal, tu me diras), ou alors j'ai rien compris
(c'est la bonne hypothese). Bref, je sais pas ou aller quand je voir
le dashboard de gdcm (alors que je sais pour VTK)...


> A mon avis ca dois etre une manip de fichier qui ne marche pas sous windobe.
> J'ai cru voir des '.' pour le repertoire courant et des trucs comme ca.
> Je sais pas bien si windobe supporte ca... a suivre
Je n'ai pas regarde' ce qu'avais fait Jean-Pierre. Je connais juste le
pendant sous notre precedente bibliotheque du labo (Libido) et il
nous avais fallut introduire une couche de portabilite' (Glib, morceau
de GTK) pour faciliter les operations de manipulation/creation de
repertoire/fichier, ainsi que la gestions des chemins.
J'en ai un souvenir penible, car la dependance a la glib posait des
problemes de packaging, et je me demandais comment les KitWare boys
contournaient ce genre de difficulte'. Des pointeurs ?

> (*) J'adore ce mot, ca marche meme en anglais :)
Oui, et ADORE lui-meme fonctionne aussi. J'adore be consistent. :)

	Eric.