[Dcmlib] Re: [Info-team] CMake vs autoconf

[Eric Boix]

	Yo,

[I dare to cross-post on dcmlib because the origin of the question seems to
 emanate from gdcm + vtk related needs. ]

Quoting Jean-Pierre Roux <Jean-Pierre.Roux at creatis.insa-lyon.fr>:
> Avant que Mathieu ne parte aux Amériques, ne pourrait-on pas faire une
> *petite* réunion pour faire le point sur les avantages/inconvenients de
> CMake par rapport aux outils plus anciens.
> Si le but de la manip est de faciliter le maintient du bazar d'installation,
> CMake presente quelque interet (*vraiment* multiplateforme ...)

The first question is the classical one of thechnology adoption for a small
developpement team i.e. "can Cmake be considered sufficiently widely accepted
for us to be adopted without being a technological risk" ?

IMVHO the answer is no. This doesn't mean Cmake is not a nice tool, nor
that it will not be widely adopted "some day". It just means (again IMHO)
that CMake is too VTK (kitware) related and it really answers some
Windows related package management deficiencies (automake/autoconf does
the job for Un*x).

The second question is: does gdcm _need_ cmake ?
Again the answer is no. The kernel of gdcm as opposed to it's vtk wrapper
doesn't require CMake (since one of the main features of CMake is to
nicely handle the VTK dependencies i.e. the includes and lib, on Windows).
In fact CMake proves to be handy for compiling the vtk wrappers of
gdcm (which is one specific usage of gdcm, allthough we tend to like
vtk a lot :). But some gdcm users wrap/embed gdcm for their own
application/data-structure and don't use vtk at all. Why should we force
those users to adopt (and install on their box) cmake when they are
allready happy with automake or dsw (VC++ projects) ?


Hence I can see two option ?
 * the "keep on trucking" lazy version:
   Let's keep all the compile tools we allready have (automake, dsw, cmake
   and distutils for python) and see who wins the rat-race. Some version
   might die by lack of developper/maintainer in the team...
 * the "clean" but expensive version:
   Let's split gdcm in two packages:
     - gdcm kernel 
     - vtk wrappers of gdcm as a contribution tool.
   In wich case the gdcm kernel classicaly requires automake + dsw,
   and the vtk wrapper part should be maintained with cmake. This clearly
   states (some will say restrict?) the CMake application field to what it
   does best i.e. deal with vtk (I wish the VTK folks provide a vtk.m4 :).

Oh well...

	Frog, back off-line for a couple weeks...