X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;f=DEVELOPPER;h=b0c1b158bdddf88e00128b59ce084e3b80bf2256;hb=HEAD;hp=f70ac33a8d41ae4dd9b9c14c8c81bea8fd9f8229;hpb=4c497616c365096ee0cba3add6b36cac7277e9cb;p=gdcm.git

diff --git a/DEVELOPPER b/DEVELOPPER
index f70ac33a..b0c1b158 100644
--- a/DEVELOPPER
+++ b/DEVELOPPER
@@ -1,105 +1 @@
-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 cmake flags you used in order to compile 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