DEVELOPPER

   1 The following comments are intended for core gdcm developpers.
   2
   3 * Compiling gdcm:
   4   - Checkout the sources to an arbitrary directory noted GDCM (e.g. ~/cvs/gdcm).
   5   - Checkout the test images to an arbitrary directory noted GDCMDATA
   6     (e.g. ~/cvs/gdcm/gdcmData).
   7   - Optionally create a temporary installation directory GDCMINSTALL e.g.
   8     mkdir /tmp/gdcminstall
   9   - Create a target directory GDCMBIN e.g.
  10     mkdir /tmp/gdcmbin
  11   - Configure cmake from GDCMBIN:
  12     cd GDCMBIN
  13     ccmake GDCM
  14       * Toggle and adjust the required options and parameters, mainly
  15         -- GDCM_DATA_ROOT should be set to GDCMDATA
  16         -- CMAKE_INSTALL_PREFIX (equivalent of --prefix of the autotools)
  17            should be set to GDCMINSTALL
  18         -- CMAKE_BUILD_TYPE set to Debug or Release
  19         -- GDCM_DOXYGEN
  20         -- GDCM_VTK When this option is on VTK_DIR might require manual
  21            configuration
  22         -- GDCM_WRAP_PYTHON
  23       * Configure cmake: hit c
  24       * Generate the makefiles (or dsw): hit g
  25   - Compile gdcm
  26     make
  27   - Run the tests manually (optional):
  28     Caveat: if you run the tests before installing, you NEED to positionate
  29             the environment variable GDCM_DICT_PATH to GDCM/Dicts e.g.
  30             export GDCM_DICT_PATH=~/cvs/gdcm/Dicts
  31     Assuming your cwd is GDCMBIN, three modes are then available:
  32     -- 1/ acces to a by number:
  33           ./Test/gdcmCxxTests
  34     -- 2/ acces to a test by it's name, by passing it as argument to
  35           gdcmCxxTests e.g.
  36           ./Test/gdcmCxxTests hashtest
  37     -- 3/ launch all the full test suite (again we assume cwd is GDCMBIN):
  38           ctest
  39           This is equivalent to "make test".
  40           Note: ctest supports the argument filtering with regexp and
  41                 the verbose mode e.g.
  42                    ctest -R print -V
  43                 proposes the tests containing "print" in their name and
  44                 makes a verbose output. For other options refer to the
  45                 documentation at http://www.cmake.org.
  46
  47 * Sending the result to kitware's dashboard (optional)
  48   ctest -D Experimental
  49   The results should appear in
  50      http://public.kitware.com/dashboard.php?name=public
  51   under the name GDCM-* within the "Experimental Builds" entry.
  52
  53 * Install gdcm (as specified by CMAKE_INSTALL_PREFIX)
  54   make install
  55   Note: the dictionaries used by gdcm are now located in
  56         CMAKE_INSTALL_PREFIX + /share/ (i.e. GDCMINSTALL + /share/ if you
  57         followed the above instructions).
  58
  59 * Python related section.
  60   Depending on the automake/autoconf/autogen.sh flags you used gdcm could
  61   be wrapped in two ways:
  62   - the first python wrappers of gdcm uses Swig (http://www.swig.org). These
  63     are the one generated when using autogen.sh --enable-python.
  64     The entry point here is the file gdcmPython/gdcm.i which uses the
  65     Swig syntax. As the last lines of this file (the ones starting
  66     with the %include directive) only some classes are wrapped for python.
  67     In theory only the library interface (basically the classes gdcmHeader
  68     and gdcmFile) should be wrapped, but the time being some additional
  69     classes are added (just to make sure those classes are Swig compatible:
  70     swig is here used as some link checker!?).
  71     Since gdcm is written in C++, Swig will produce two different outputs:
  72       -- some C based low level wrapper (see gdcmPython/gdcm_wrap.c)
  73       -- some Python based object oriented so called "shadow classes" (see
  74          file gdcmPython/gdcm.py)
  75     We also added the file gdcmPython/__init__.py which is the one that
  76     actually gets loaded when one uses the gdcmPython Python package.
  77     The file __init__.py loads the Swig generated shadow classes (gdcm.py)
  78     but will only re-export the interface of gdcm which corresponds to
  79     the lines :
  80        gdcmHeader = gdcm.gdcmHeader
  81        gdcmDictSet = gdcm.gdcmDictSet
  82        gdcmFile = gdcm.gdcmFile
  83        [etc.]
  84     Hence this whole Swig wrapping process is quite odd since we shall
  85     wrap more classes (%include in swig.i) that eventually get exported to
  86     the final user by gdcmPython/__init__.py.
  87   - the second python wrappers uses the vtk (http://public.kitware.com/VTK/)
  88     native wrappers i.e. the binary vtkWrapPython. But it should be noticed
  89     that the purpose is here a bit different than the one of the Swig
  90     generated Python wrappers. When using vtkWrapPython the goal is to
  91     wrap a single vtk class namely vtkGdcmReader as defined in files
  92     vtk/vtkGdcmReader.h and vtk/vtkGdcmReader.cxx (and of course those
  93     files are hand made vtk oriented wrappers of gdcm).
  94     Those wrappers are the one generated when using
  95        autogen.sh --enable-python --enable-vtk
  96   - In order to understand the difference between both wrappers you should
  97     compare both demo scripts gdcmPython/demo/vtkGdcmDemo.py and
  98     gdcmPython/demo/vtkGdcmReader.py. The first one only uses the
  99     Swig wrapped classes ("from gdcmPython import gdcmHeader') as opposed
 100     to vtkGdcmReader.py which also uses vtkWrapPython wrapped classes
 101     ("from gdcmPython.vtkgdcmPython import *").
 102