-The following comments are intended for core gdcm developpers.
-
-* Compiling gdcm:
- - Checkout the sources to an arbitrary directory noted GDCM (e.g. ~/cvs/gdcm).
- - Checkout the test images to an arbitrary directory noted GDCMDATA
- (e.g. ~/cvs/gdcm/gdcmData).
- - Optionally create a temporary installation directory GDCMINSTALL e.g.
- mkdir /tmp/gdcminstall
- - Create a target directory GDCMBIN e.g.
- mkdir /tmp/gdcmbin
- - Configure cmake from GDCMBIN:
- cd GDCMBIN
- ccmake GDCM
- * Toggle and adjust the required options and parameters, mainly
- -- GDCM_DATA_ROOT should be set to GDCMDATA
- -- CMAKE_INSTALL_PREFIX (equivalent of --prefix of the autotools)
- should be set to GDCMINSTALL
- -- CMAKE_BUILD_TYPE set to Debug or Release
- -- GDCM_DOXYGEN
- -- GDCM_VTK When this option is on VTK_DIR might require manual
- configuration
- -- GDCM_WRAP_PYTHON
- * Configure cmake: hit c
- * Generate the makefiles (or dsw): hit g
- - Compile gdcm
- make
- - Run the tests manually (optional):
- Caveat: if you run the tests before installing, you NEED to positionate
- the environment variable GDCM_DICT_PATH to GDCM/Dicts e.g.
- export GDCM_DICT_PATH=~/cvs/gdcm/Dicts
- Assuming your cwd is GDCMBIN, three modes are then available:
- -- 1/ acces to a by number:
- ./Test/gdcmCxxTests
- -- 2/ acces to a test by it's name, by passing it as argument to
- gdcmCxxTests e.g.
- ./Test/gdcmCxxTests hashtest
- -- 3/ launch all the full test suite (again we assume cwd is GDCMBIN):
- ctest
- This is equivalent to "make test".
- Note: ctest supports the argument filtering with regexp and
- the verbose mode e.g.
- ctest -R print -V
- proposes the tests containing "print" in their name and
- makes a verbose output. For other options refer to the
- documentation at http://www.cmake.org.
-
-* Sending the result to kitware's dashboard (optional)
- ctest -D Experimental
- The results should appear in
- http://public.kitware.com/dashboard.php?name=public
- under the name of your machine (uname), but for ease of use you can
- change the SITE variable in your CMakeCache.txt to something more
- accurate such as: GDCM-my_machine_name. The entry will then be within
- the "Experimental Builds" entry.
-
-* Install gdcm (as specified by CMAKE_INSTALL_PREFIX)
- make install
- Note: the dictionaries used by gdcm are now located in
- CMAKE_INSTALL_PREFIX + /share/ (i.e. GDCMINSTALL + /share/ if you
- followed the above instructions).
-
-* Python related section.
- Depending on the automake/autoconf/autogen.sh flags you used gdcm could
- be wrapped in two ways:
- - the first python wrappers of gdcm uses Swig (http://www.swig.org). These
- are the one generated when using autogen.sh --enable-python.
- The entry point here is the file gdcmPython/gdcm.i which uses the
- Swig syntax. As the last lines of this file (the ones starting
- with the %include directive) only some classes are wrapped for python.
- In theory only the library interface (basically the classes gdcmHeader
- and gdcmFile) should be wrapped, but the time being some additional
- classes are added (just to make sure those classes are Swig compatible:
- swig is here used as some link checker!?).
- Since gdcm is written in C++, Swig will produce two different outputs:
- -- some C based low level wrapper (see gdcmPython/gdcm_wrap.c)
- -- some Python based object oriented so called "shadow classes" (see
- file gdcmPython/gdcm.py)
- We also added the file gdcmPython/__init__.py which is the one that
- actually gets loaded when one uses the gdcmPython Python package.
- The file __init__.py loads the Swig generated shadow classes (gdcm.py)
- but will only re-export the interface of gdcm which corresponds to
- the lines :
- gdcmHeader = gdcm.gdcmHeader
- gdcmDictSet = gdcm.gdcmDictSet
- gdcmFile = gdcm.gdcmFile
- [etc.]
- Hence this whole Swig wrapping process is quite odd since we shall
- wrap more classes (%include in swig.i) that eventually get exported to
- the final user by gdcmPython/__init__.py.
- - the second python wrappers uses the vtk (http://public.kitware.com/VTK/)
- native wrappers i.e. the binary vtkWrapPython. But it should be noticed
- that the purpose is here a bit different than the one of the Swig
- generated Python wrappers. When using vtkWrapPython the goal is to
- wrap a single vtk class namely vtkGdcmReader as defined in files
- vtk/vtkGdcmReader.h and vtk/vtkGdcmReader.cxx (and of course those
- files are hand made vtk oriented wrappers of gdcm).
- Those wrappers are the one generated when using
- autogen.sh --enable-python --enable-vtk
- - In order to understand the difference between both wrappers you should
- compare both demo scripts gdcmPython/demo/vtkGdcmDemo.py and
- gdcmPython/demo/vtkGdcmReader.py. The first one only uses the
- Swig wrapped classes ("from gdcmPython import gdcmHeader') as opposed
- to vtkGdcmReader.py which also uses vtkWrapPython wrapped classes
- ("from gdcmPython.vtkgdcmPython import *").
-
+The entry point is Doc/Website/Developpers.html
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff