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

[Mathieu Malaterre]

Eric Boix wrote:
> 	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).

I don't want to start a flame. But I couldn't stay quiet. I perfectly 
understand that my opinion is biased (due to my next employment). But I 
just wanted to share my /very small/ experience with gdcm.

The first question is for me: what is gdcm for ?
  A: Reading Dicom
  So nice, I can read dicom, and write dicom. I can export to acr, to 
raw... And then ? Doesn't CREATIS whole job is about image 
*interpretation* so DICOM is just a wide standard after all. But the 
real work, -la valeur ajoutée- of CREATIS is building software that 
interprate/work on images. The info-team choose VTK and wxWindows for 
that. The info team also choose to support both wxWindows *and* Linux.

	Thus, shouldn't we think *for real* about tools that ease cross 
plateform dvpt and integration with wxWindows and VTK ?

> 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) ?

	I never say that everybody should use CMake in the lab. I only said 
that GDCM dvpt would be *so* much easier if we choose the right tool. 
Just think of some considderations:

	- VC++ is not supported any more, or not in the near future, thus how 
much time do think you'll need to adapt dsw thingies to VC.NET ? Is it 
worth time spending on this transition ?
	- Borland has just bought part of wxWindows(*), and there next IDE 
tool, will be extremely easy to use, and still would be link to 
wxWindows. Don't you think about changing to Borland ? Then again how 
much time will you need to port gdcm for Borland.

	You are saying CMake is a pain bacause, you need to install CMake. But 
to run, cmake only need one thing: 'CMake' itself. Compared to (**):
	[A typical configure script depends on:
sh, sed, echo, /dev/null, test, chmod, hostname, and cat.  In short,
a fairly complete UNIX environment.  So, CMake depends on the one common
tool, the c/c++ compiler.   It was felt that for a c/c++ project this 
would not be too much to ask. The union of available shell functions is 
very small across windows and UNIX.  CMake is in a sense a small 
portable shell.]

	And CMake already solves these issues. Now I can't force anybody to use 
CMake. So let's see the options:

> 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 :).

	Instead of package can't we just do branching/tagging ?

'cvs co gdcm-cmake'  vs. 'cvs co gdcm'

Mathieu
Ps: Please note that I am deeply convinced in CMake as I had to do gdcm 
cross compiling and it was a pain in the neck to synchronise...


(*)
http://wxwindows.org/borland01.htm

(**)
http://www.cmake.org/pipermail/cmake/2003-November/004474.html