[Dcmlib] python build & install

[Eric Boix]

	Yo Mathieu,

Quoting Mathieu Malaterre <mathieu.malaterre at kitware.com>:
>    bonne nouvelle les deux modes marche a nouveau. Les scripts sont
> nettement plus simples, juste setup.py.in pas de MANIFEST ni de pythonerie
> non maintenable. cmake fais tous le boulot et setup fais juste que copier
> a la bonne place. 
Hummm, je suis agreablement surpris. On teste cela !

>   En fait la question maintenant est est-ce vraiment necessaire de faire tout
> ca via setup.py.in et pas via cmake ? Un utilisateur peut etre etonner de
> faire 'make install' pour les lib c++, puis devoir faire explicitement
> 'python setup.py install' ... enfin bon voila
Ben, en theorie un pythoneur pur ne devrait pas avoir besoin de faire cmake !
En effet, setup.py sait:
  - recompiler (make)
  - installer (make install)
  - packager des sources (en rpm ou Win32 autoinstaller)
  - packer des binaires  (en rpm ou Win32 autoinstaller).
Initialement (avant cmake), un pythoneur n'avait donc pas besoin des
autotools ni des .dsw-.dsp faits manuellement pour faire toutes les
taches necessaires.
Il faisait directement (et au prix des Swig.py et VTK.py qui viennent patcher
setup.py):
  python setup.py sdist
  python setup.py bdist --formats=rpm

Maitenant que cmake est passe' par la, on est un peu dans un mode
hybride qui va a l'encontre de l'esprit de setup.py...
Heueu, je ne sais qu'en penser, mais si dans l'etat actuel des choses
je peux packager (pour un utilisateur python pur) en faisant un truc du
style:
 - ccmake
 - make
 - python setup.py sdist
 - python setup.py bdist --formats=rpm (ou win32),
alors je pense que l'on a gagne' du temps...

Ceci dit, maintenant que cmake rulez, a terme on peut envisager de
se debarasser de ce setup.py a condition:
 1/ d'ecrire le .spec pour les rpm qui packagera
    - les sources,
    - les binaires,
    - les pythoneries
   et la` Fabrice Bellet sait deja faire (pour ITK et VTK)
 2/ l'equivalent a coup de Innosetup pour Win32...
   et la` Benoit Regrain sait faire !
 
>   Comme je suis tetu et j'ai tout mis sous un namespace 'gdcm', avec un
> repertoire gdcmPython, j'espere que tout le monde sera content avec ca.
Probablement pas, mais ceux qui ne s'en contenteront pas pourrons aisement
modifier ce que tu as fait ! C'est deja nettement plus simple... 

> En parlant de namespace j'ai modifier gdcmUtil pour etre une classe avec
> que des methodes statiques, ca change rien, je trouve ca plus propre
> que des methodes globales a la 'C'.
Cool ! 100% pour !

	Frog.