In the beginning of the 1990s, the DCMTK (or to be more precise its predecessor European CTN) started as a Unix-only DICOM toolkit. So, it was an easy decision to use GNU Autoconf (aka configure) at some point in time when the number of supported platforms went up. Later on, also support for the Windows operating system was added to the DCMTK. Initially, the project/make files for the Visual C++ compiler were created and maintained manually. Starting with version 3.5.3, DCMTK was shipped with CMake project files for improved configuration on Windows systems. The old manually created project/make files were removed with version 3.5.4, so CMake is required to generate project files on Windows since then.
Over the years, many people asked for extending the use of CMake to other platforms than Windows and, in fact, we also received a couple of revised CMake project files from some dedicated DCMTK users. However, it took us some time to incorporate these changes and to compile a set of reworked CMake project files that fulfill our requirements. DCMTK 3.6.0 was the first release that also supports CMake on Unix systems. Nevertheless, the “old” (or better say: well-established) GNU autoconf files are still part of the source code package. We haven’t decided yet if and when they will be removed, because there is still some work to do regarding the CMake project files in order to fully replace the good old configure mechanism.
Anyway, we really appreciate what CMake provides to a toolkit maintainer, e.g. for building shared libraries on different platforms. Also the testing framework that has been introduced only recently to the DCMTK already supports CMake’s way of doing this (based on CTest). The next logical step will probably be to set up a testing server using CDash in order to automatically compile and perform tests on a multitude of platforms. We are also dreaming of facilitating the creation of binary packages using CPack, which is also part of the CMake system. A first step has already been done by splitting the “make install” target into separate installation components, e.g. for binary executables and development files.