[Dcmlib] [Fwd: patch]

[Mathieu Malaterre]

Eric Boix wrote:
> 	Salut Mathieu,
> 
> Quoting Mathieu Malaterre <mathieu.malaterre at kitware.com>:
> 
>>ca marche avec mon g++ 3.3, qu'est ce que ca dis chez toi ?
> 
> frog(frog): g++ --version
>    g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
> frog(frog): g++ !$
>    g++ junk.cc
> frog(frog): a.out
>    const char constructor
> 
> Heueu, ben du coup je comprends plus. Pourtant apres un debug
> au sein de gdcm, c'est bien le constructeur booleen qui est invoque'.
> Peut-etre qu'avec les couches d'heritage cela se complique !?
> 
> 
>>Ok Brad me confirme que c++ choisit la methode en fonction de la
>>complexite. Dans notre cas il est beaucoup plus simple de caster un
>>pointer (const char) en bool que de construire une std::string.
> 
> Oh well. Shit happens. Ceci n'explique pas pourquoi le explicit
> ne regle pas les choses.

D'apres mes souvenirs le explicit c'est pour le constucteur par copie, 
du genre:

class foo{
  explicit foo();
}

foo a();
foo b = a; //<- passe pas
foo b( a ); // ok


>>Donc ok j'appliquerais un patch des que j'ai le feu vert de JP.
> 
> En testant sous Win32 avec Benoit Regrain, VC++ emet des warnings
> sur les nombreuses occurences de ce pb. Donc on est sur de pas oublier
> de commiter, des que JPR se sera remis de l'acceleration des commits.
> 
> Il faudra que l'on recause des pythoneries. Avec Benoit on a pas
> compris pourquoi cmake genere un gdcmPython/__init__.py aussi simpliste.

Inversement je comprenais pas pourquoi __init__.py dans gdcm etait si 
complique :P

Plus serieusement, je voulais *reellement* simplifier __init__
En gros il doit juste charger la lib _gdcm ( via le script gdcm.py ) 
c'est tout. Dans le votre:

1. Les GDCM_DICT_PATH/GDCM_DATA_PATH devraient etre hardcode dans GDCM, 
(sinon on duplique et c'est plus synchronise).

2. Le coup de import gdcm vs from gdcm import *, je pense l'avoir resolu 
  avec le fichier .pth

3. Et finalement ce qui reste c'est la differenciation build vs install, 
et c'est vrai que je prefere l'approche dans VTK. Mais c'est histoire de 
gout. Si avec votre approche on peut gerer plusieurs build (genre un 
gdcm avec gcc-2.85, un gcc-3.3, un gcc-3.4, un avec/sans vtk...), c'est 
ma seule requete.



> Par ailleurs, je ne suis pas persuade' qu'il soit une bonne chose
> d'avoir cmake pour pouvoir utiliser le setup.py (en tout cas c'est pas
> dans la philosophie de distutils). Je regarde cela d'un peu plus pres
> avant de critiquer plus avant !

Mon seul but c'est d'eviter de dupliquer du code en python qui peut 
(dois!) etre fais en c++. Vraiment pour moi le setup.py c'est parce que 
cmake ne s'est pas installer "a la python". Donc tout ce que je veut de 
setup.py c'est qu'il me copie:
- gdcm.py
- _gdcm.so
- libvtkgdcmPython.so


Voila
Mathieu