#EXTRA_DIST = \
# DoxyfileDeveloppers \
# DoxyfileUsers \
-# DoxyDevelInstal.txt \
-# DoxyIntroduction.txt \
# DoxyPython.txt \
-# DoxyInstallation.txt \
# DoxyMainPage.txt
IF(GDCM_DOCUMENTATION)
# http://www.cmake.org/pipermail/cmake/2003-April/003673.html
# Too bad CMake doesn't support multiline ""
- SET(GDCM_DOCUMENTATION_INPUT_COMMON
- "${GDCM_SOURCE_DIR}/src ${GDCM_SOURCE_DIR}/Doc/DoxyPython.txt ${GDCM_SOURCE_DIR}/Doc/DoxyInstallation.txt ${GDCM_SOURCE_DIR}/Doc/DoxyIntroduction.txt"
+ SET(GDCM_DOXYGEN_INPUT_COMMON
+ "${GDCM_SOURCE_DIR}/src ${GDCM_SOURCE_DIR}/Doc/DoxyPython.txt"
)
SET(GDCM_DOCUMENTATION_EXCLUDE_COMMON
)
SET(GDCM_HTML_OUTPUT
html.developper
)
- SET(GDCM_DOCUMENTATION_INPUT
- "${GDCM_DOCUMENTATION_INPUT_COMMON} ${GDCM_SOURCE_DIR}/Doc/DoxyDevelInstal.txt ${GDCM_SOURCE_DIR}/Doc/DoxyMainPage.txt"
+ SET(GDCM_DOXYGEN_INPUT
+ "${GDCM_DOXYGEN_INPUT_COMMON} ${GDCM_SOURCE_DIR}/Doc/DoxyMainPage.txt"
)
SET(GDCM_DOCUMENTATION_EXCLUDE
"${GDCM_DOCUMENTATION_EXCLUDE_COMMON} ${GDCM_SOURCE_DIR@/src/iddcmjpeg.h ${GDCM_SOURCE_DIR@/src/src/gdcmJpeg.cxx"
+++ /dev/null
-/**
- * \page DoxyDevelInstal Developpers workspace
- * There is no further requirements than the ones of \ref DoxyInstallation.
- * But the developpers generally have further needs than the library user
- * like :
- * - in place debugging (in place as opposed to fully
- * installed, i.e. when working in the cvs hierarchy or in the hierarchy
- * build from gdcm source tar ball).
- * - tests of features
- * - test suite usage (typically after code modifications and prior to
- * commit).
- * .
- * In the following we shall assume that gdcm is already compiled-
- * BUT not installed- in a directory named <TT>GDCM_HOME</TT>.
- *
- * \section DoxyDevelInstalCPlusPlus Working with C++
- * The kernel library uses the environnement variable
- * <TT>GDCM_DICT_PATH</TT> as a path to the location of the default
- * Dicom dictionary. Hence if you which to work/debug a code based
- * on gdcm, you first need to positionate this variable. When omitting
- * this you should get the following message:
- * <TT>gdcmDict::gdcmDict: can't open dictionary /usr/local/share/gdcm/dicomV3.dic</TT>
- *
- * Suppose you want to launch some C++ demo/test program, that
- * gets compiled with the kernel, e.g. PrintHeader. One can do
- * - <TT>cd GDCM_HOME</TT>
- * - <TT>export GDCM_DICT_PATH=`pwd`/Dicts</TT>
- * - <TT>cd Test</TT>
- * - <TT>./PrintHeader</TT>
- * .
- * \section DoxyDevelInstalPython Working with Python
- * - <TT>cd GDCM_HOME</TT>
- * - <TT>./autogen.sh --enable-python</TT>
- * - <TT>make</TT>
- * - <TT>export PYTHONPATH=`pwd`</TT>
- * - <TT>cd gdcmPython</TT>
- * - <TT>ln -s .libs/pygdcm.so _gdcm.so</TT> (this is because automake
- * doesn't allow the building of libraries whose name starts with an
- * underscore. Since we need the wrapper library to be named _gdcm
- * [because swig automaticatily uses this name when building the
- * shadow classes], automake generates pygdcm.so and at install stage
- * stage renames it to _gdcm.so).
- * - You can then use gdcmPython for manual test/demos
- * -# <TT>cd GDCM_HOME/gdcmPython/demo</TT>
- * -# <TT>python PrintHeader.py</TT>
- * - You can also run the gdcm test suite, which is written in Python:
- * -# first you need to install the Dicom data files used by the
- * test suite. The cvs access point is
- * <TT>:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public</TT>
- * and the name of the module is <TT>gdcmData</TT>.
- * Checkout this module in <TT>GDCM_HOME</TT> directory
- * -# <TT>cd GDCM_HOME/gdcmPython/</TT>
- * -# <TT>python testSuite.py</TT>
- */
+++ /dev/null
-/**
- * \page DoxyInstallation Installing gdcm and gdcmPython
- * \section DoxyRequirements Requirements
- * - For the core C++ library you shall need a C++ compiler with the
- * "list" and "map" STL containers. Gdcm is developped and tested under:
- * -# GNU/linux (gcc 2.96.x)
- * -# Win32/VC++ 6.x
- * .
- * - For \ref DoxyPythonComplete you shall need:
- * -# <A HREF="http://www.python.org/2.2.2/">Python version 2.2.x</A>
- * -# <A HREF="http://www.swig.org">Swig</A> version >= 1.3.17x (in order
- * to handle C++ member overloading, shadow classes and static methods)
- * \htmlonly
- * <UL>
- * <LI>Rpms for GNU/linux:
- * <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.i386.rpm">
- * swig13-1.3.17-1.i386.rpm</A>,
- * <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.src.rpm">
- * swig13-1.3.17-1.src.rpm</A>.
- * <LI>for Win32 you shall need to compile
- * <A HREF="http://www.swig.org/download.html">the sources</A>
- * </UL>
- * \endhtmlonly
- * .
- * .
- *
- * \section DoxyInstallLinux Un*x
- * \subsection DoxyInstallLinuxCvs Starting from cvs sources.
- * - Retrieve the
- * <A HREF="http://www.creatis.insa-lyon.fr/Public/Gdcm/cvs.html">
- * sources through cvs</A>,
- * - <TT>cd gdcm</TT>
- * - <TT>./autogen.sh --help</TT> in order to select your preferences
- * - <TT>./autogen.sh</TT> to launch the usual automake/autoconf
- * process e.g.
- * -# <TT>./autogen.sh --prefix=/where/ever/you/want</TT>
- * to configure the script to force installation in a specified
- * place.
- * -# <TT>./autogen.sh --enable-python</TT> to generate the
- * python wrappers (a.k.a. gdcmPython)
- * -# <TT>./autogen.sh --enable-vtk</TT> to generate the
- * vtk clases that shallow wrap gdcm,
- * -# <TT>./autogen.sh --enable-doxygen</TT> to generate the
- * <A HREF="http://www.doxygen.org/">doxygen</A>
- * based documentation
- * .
- * .
- * - <TT>make</TT>
- * - <TT>make instal</TT>
- * - As usual, you can optionnally:
- * -# <TT>make clean</TT>
- * -# <TT>make CFLAGS='-g' CXXFLAGS='-DPUB_DICT_PATH=\"/usr/local/share/gdcm/\" -D__STDC_LIMIT_MACROS'</TT>
- * if you are in hurry and want to omit "-g -O2" default flags
- * -# <TT>make snapshot</TT>
- * .
- *
- * \subsection DoxyInstallLinuxSources Starting from the sources (snapshot).
- * The process is exactly the same as the one using the cvs sources
- * (see above) except that you shall use <TT>./configure</TT> instead
- * of <TT>./autogen.sh</TT>
- *
- * \section DoxyInstallWindoze Windows
- * - Retrieve the sources through the tarball
- * - Launch VC++ by opening the <TT>gdcm.dsw</TT> workspace.
- * - Proceed with building the required projects.
- * .
- */
/**
* \mainpage gdcm documentation
*
- * - \ref DoxyIntroduction
- * - \ref DoxyInstallation
- * - \ref DoxyPythonComplete
- * - \ref DoxyDevelInstal
- * - <A HREF="hierarchy.html">Class Hierarchy</A>
- * - <A HREF="classes.html">Alphabetical List</A>
- * - <A HREF="annotated.html">Compound List</A>
- * - <A HREF="files.html">File List</A>
- * - <A HREF="functions.html">Compound Members</A>
- * - <A HREF="globals.html">File Members</A>
+ * This is the developpers documentation.
*/
/**
* \mainpage gdcm documentation
*
- * - \ref DoxyIntroduction
- * - \ref DoxyInstallation
- * - \ref DoxyPythonComplete
- * - <A HREF="hierarchy.html">Class Hierarchy</A>
- * - <A HREF="classes.html">Alphabetical List</A>
- * - <A HREF="annotated.html">Compound List</A>
- * - <A HREF="files.html">File List</A>
- * - <A HREF="functions.html">Compound Members</A>
- * - <A HREF="globals.html">File Members</A>
+ * This is the users documentation
*/
+++ /dev/null
-# Doxyfile 1.3.3
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project
-#
-# All text after a hash (#) is considered a comment and will be ignored
-# The format is:
-# TAG = value [value, ...]
-# For lists items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (" ")
-
-#---------------------------------------------------------------------------
-# General configuration options
-#---------------------------------------------------------------------------
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
-# by quotes) that should identify the project.
-
-PROJECT_NAME = gdcm
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number.
-# This could be handy for archiving the generated documentation or
-# if some version control system is used.
-
-PROJECT_NUMBER =
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
-# base path where the generated documentation will be put.
-# If a relative path is entered, it will be relative to the location
-# where doxygen was started. If left blank the current directory will be used.
-
-OUTPUT_DIRECTORY =
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# The default language is English, other supported languages are:
-# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch,
-# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en
-# (Japanese with English messages), Korean, Norwegian, Polish, Portuguese,
-# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.
-
-OUTPUT_LANGUAGE = English
-
-# This tag can be used to specify the encoding used in the generated output.
-# The encoding is not always determined by the language that is chosen,
-# but also whether or not the output is meant for Windows or non-Windows users.
-# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
-# forces the Windows encoding (this is the default for the Windows binary),
-# whereas setting the tag to NO uses a Unix-style encoding (the default for
-# all platforms other than Windows).
-
-USE_WINDOWS_ENCODING = NO
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available.
-# Private class members and static file members will be hidden unless
-# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
-
-EXTRACT_ALL = YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
-# will be included in the documentation.
-
-EXTRACT_PRIVATE = YES
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file
-# will be included in the documentation.
-
-EXTRACT_STATIC = YES
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
-# defined locally in source files will be included in the documentation.
-# If set to NO only classes defined in header files are included.
-
-EXTRACT_LOCAL_CLASSES = YES
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
-# undocumented members of documented classes, files or namespaces.
-# If set to NO (the default) these members will be included in the
-# various overviews, but no documentation section is generated.
-# This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy.
-# If set to NO (the default) these class will be included in the various
-# overviews. This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_CLASSES = NO
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
-# friend (class|struct|union) declarations.
-# If set to NO (the default) these declarations will be included in the
-# documentation.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
-# documentation blocks found inside the body of a function.
-# If set to NO (the default) these blocks will be appended to the
-# function's detailed documentation block.
-
-HIDE_IN_BODY_DOCS = NO
-
-# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
-# include brief member descriptions after the members that are listed in
-# the file and class documentation (similar to JavaDoc).
-# Set to NO to disable this.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
-# the brief description of a member or function before the detailed description.
-# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-
-REPEAT_BRIEF = YES
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# Doxygen will generate a detailed section even if there is only a brief
-# description.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited
-# members of a class in the documentation of that class as if those members were
-# ordinary class members. Constructors, destructors and assignment operators of
-# the base classes will not be shown.
-
-INLINE_INHERITED_MEMB = YES
-
-# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
-# path before files name in the file list and in the header files. If set
-# to NO the shortest path that makes the file name unique will be used.
-
-FULL_PATH_NAMES = YES
-
-# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
-# can be used to strip a user defined part of the path. Stripping is
-# only done if one of the specified strings matches the left-hand part of
-# the path. It is allowed to use relative paths in the argument list.
-
-STRIP_FROM_PATH =
-
-# The INTERNAL_DOCS tag determines if documentation
-# that is typed after a \internal command is included. If the tag is set
-# to NO (the default) then the documentation will be excluded.
-# Set it to YES to include the internal documentation.
-
-INTERNAL_DOCS = NO
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
-# file names in lower case letters. If set to YES upper case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# users are adviced to set this option to NO.
-
-CASE_SENSE_NAMES = YES
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
-# (but less readable) file names. This can be useful is your file systems
-# doesn't support long names like on DOS, Mac, or CD-ROM.
-
-SHORT_NAMES = NO
-
-# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
-# will show members with their full class and namespace scopes in the
-# documentation. If set to YES the scope will be hidden.
-
-HIDE_SCOPE_NAMES = NO
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
-# will generate a verbatim copy of the header file for each class for
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS = YES
-
-# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
-# will put list of the files that are included by a file in the documentation
-# of that file.
-
-SHOW_INCLUDE_FILES = YES
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
-# will interpret the first line (until the first dot) of a JavaDoc-style
-# comment as the brief description. If set to NO, the JavaDoc
-# comments will behave just like the Qt-style comments (thus requiring an
-# explict @brief command for a brief description.
-
-JAVADOC_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
-# treat a multi-line C++ special comment block (i.e. a block of //! or ///
-# comments) as a brief description. This used to be the default behaviour.
-# The new default is to treat a multi-line C++ comment block as a detailed
-# description. Set this tag to YES if you prefer the old behaviour instead.
-
-MULTILINE_CPP_IS_BRIEF = NO
-
-# If the DETAILS_AT_TOP tag is set to YES then Doxygen
-# will output the detailed description near the top, like JavaDoc.
-# If set to NO, the detailed description appears after the member
-# documentation.
-
-DETAILS_AT_TOP = NO
-
-# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
-# member inherits the documentation from any documented member that it
-# reimplements.
-
-INHERIT_DOCS = YES
-
-# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
-# is inserted in the documentation for inline members.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
-# will sort the (detailed) documentation of file and class members
-# alphabetically by member name. If set to NO the members will appear in
-# declaration order.
-
-SORT_MEMBER_DOCS = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab.
-# Doxygen uses this value to replace tabs by spaces in code fragments.
-
-TAB_SIZE = 8
-
-# The GENERATE_TODOLIST tag can be used to enable (YES) or
-# disable (NO) the todo list. This list is created by putting \todo
-# commands in the documentation.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable (YES) or
-# disable (NO) the test list. This list is created by putting \test
-# commands in the documentation.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable (YES) or
-# disable (NO) the bug list. This list is created by putting \bug
-# commands in the documentation.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
-# disable (NO) the deprecated list. This list is created by putting
-# \deprecated commands in the documentation.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# This tag can be used to specify a number of aliases that acts
-# as commands in the documentation. An alias has the form "name=value".
-# For example adding "sideeffect=\par Side Effects:\n" will allow you to
-# put the command \sideeffect (or @sideeffect) in the documentation, which
-# will result in a user defined paragraph with heading "Side Effects:".
-# You can put \n's in the value part of an alias to insert newlines.
-
-ALIASES =
-
-# The ENABLED_SECTIONS tag can be used to enable conditional
-# documentation sections, marked by \if sectionname ... \endif.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
-# the initial value of a variable or define consist of for it to appear in
-# the documentation. If the initializer consists of more lines than specified
-# here it will be hidden. Use a value of 0 to hide initializers completely.
-# The appearance of the initializer of individual variables and defines in the
-# documentation can be controlled using \showinitializer or \hideinitializer
-# command in the documentation regardless of this setting.
-
-MAX_INITIALIZER_LINES = 30
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
-# only. Doxygen will then generate output that is more tailored for C.
-# For instance some of the names that are used will be different. The list
-# of all members will be omitted, etc.
-
-OPTIMIZE_OUTPUT_FOR_C = NO
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources
-# only. Doxygen will then generate output that is more tailored for Java.
-# For instance, namespaces will be presented as packages, qualified scopes
-# will look different, etc.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
-# at the bottom of the documentation of classes and structs. If set to YES the
-# list will mention the files that were used to generate the documentation.
-
-SHOW_USED_FILES = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated
-# by doxygen. Possible values are YES and NO. If left blank NO is used.
-
-QUIET = NO
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated by doxygen. Possible values are YES and NO. If left blank
-# NO is used.
-
-WARNINGS = YES
-
-# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
-# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
-# automatically be disabled.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some
-# parameters in a documented function, or documenting parameters that
-# don't exist or using markup commands wrongly.
-
-WARN_IF_DOC_ERROR = YES
-
-# The WARN_FORMAT tag determines the format of the warning messages that
-# doxygen can produce. The string should contain the $file, $line, and $text
-# tags, which will be replaced by the file and line number from which the
-# warning originated and the warning text.
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning
-# and error messages should be written. If left blank the output is written
-# to stderr.
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag can be used to specify the files and/or directories that contain
-# documented source files. You may enter file names like "myfile.cpp" or
-# directories like "/usr/src/myproject". Separate the files or directories
-# with spaces.
-
-INPUT = ../src DoxyPython.txt DoxyMainPage.txt \
- DoxyInstallation.txt DoxyDevelInstal.txt \
- DoxyPython.txt DoxyIntroduction.txt
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank the following patterns are tested:
-# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp
-# *.h++ *.idl *.odl
-
-FILE_PATTERNS = *.cxx *.h
-
-# The RECURSIVE tag can be used to turn specify whether or not subdirectories
-# should be searched for input files as well. Possible values are YES and NO.
-# If left blank NO is used.
-
-RECURSIVE = NO
-
-# The EXCLUDE tag can be used to specify files and/or directories that should
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-
-EXCLUDE = ../src/iddcmjpeg.h ../src/gdcmJpeg.cxx
-
-# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories
-# that are symbolic links (a Unix filesystem feature) are excluded from the input.
-
-EXCLUDE_SYMLINKS = NO
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories.
-
-EXCLUDE_PATTERNS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or
-# directories that contain example code fragments that are included (see
-# the \include command).
-
-EXAMPLE_PATH = ../gdcmPython/demo
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank all files are included.
-
-EXAMPLE_PATTERNS =
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude
-# commands irrespective of the value of the RECURSIVE tag.
-# Possible values are YES and NO. If left blank NO is used.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or
-# directories that contain image that are included in the documentation (see
-# the \image command).
-
-IMAGE_PATH =
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command <filter> <input-file>, where <filter>
-# is the value of the INPUT_FILTER tag, and <input-file> is the name of an
-# input file. Doxygen will then use the output that the filter program writes
-# to standard output.
-
-INPUT_FILTER =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER) will be used to filter the input files when producing source
-# files to browse.
-
-FILTER_SOURCE_FILES = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will
-# be generated. Documented entities will be cross-referenced with these sources.
-
-SOURCE_BROWSER = YES
-
-# Setting the INLINE_SOURCES tag to YES will include the body
-# of functions and classes directly in the documentation.
-
-INLINE_SOURCES = YES
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the REFERENCED_BY_RELATION tag is set to YES (the default)
-# then for each documented function all documented
-# functions referencing it will be listed.
-
-REFERENCED_BY_RELATION = YES
-
-# If the REFERENCES_RELATION tag is set to YES (the default)
-# then for each documented function all documented entities
-# called/used by that function will be listed.
-
-REFERENCES_RELATION = YES
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
-# will generate a verbatim copy of the header file for each class for
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
-# of all compounds will be generated. Enable this if the project
-# contains a lot of classes, structs, unions or interfaces.
-
-ALPHABETICAL_INDEX = YES
-
-# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
-# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
-# in which this list will be split (can be a number in the range [1..20])
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all
-# classes will be put under the same header in the alphabetical index.
-# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
-# should be ignored while generating the index headers.
-
-IGNORE_PREFIX =
-
-#---------------------------------------------------------------------------
-# configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
-# generate HTML output.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `html' will be used as the default path.
-
-HTML_OUTPUT = html.developper
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
-# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
-# doxygen will generate files with .html extension.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a personal HTML header for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard header.
-
-HTML_HEADER =
-
-# The HTML_FOOTER tag can be used to specify a personal HTML footer for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard footer.
-
-HTML_FOOTER =
-
-# The HTML_STYLESHEET tag can be used to specify a user defined cascading
-# style sheet that is used by each HTML page. It can be used to
-# fine-tune the look of the HTML output. If the tag is left blank doxygen
-# will generate a default style sheet
-
-HTML_STYLESHEET =
-
-# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
-# files or namespaces will be aligned in HTML using tables. If set to
-# NO a bullet list will be used.
-
-HTML_ALIGN_MEMBERS = YES
-
-# If the GENERATE_HTMLHELP tag is set to YES, additional index files
-# will be generated that can be used as input for tools like the
-# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
-# of the generated HTML documentation.
-
-GENERATE_HTMLHELP = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
-# controls if a separate .chi index file is generated (YES) or that
-# it should be included in the master .chm file (NO).
-
-CHM_FILE =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
-# be used to specify the file name of the resulting .chm file. You
-# can add a path in front of the file if the result should not be
-# written to the html output dir.
-
-HHC_LOCATION =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
-# be used to specify the location (absolute path including file name) of
-# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
-# the HTML help compiler on the generated index.hhp.
-
-GENERATE_CHI = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
-# controls whether a binary table of contents is generated (YES) or a
-# normal table of contents (NO) in the .chm file.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members
-# to the contents of the Html help documentation and to the tree view.
-
-TOC_EXPAND = NO
-
-# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
-# top of each HTML page. The value NO (the default) enables the index and
-# the value YES disables it.
-
-DISABLE_INDEX = NO
-
-# This tag can be used to set the number of enum values (range [1..20])
-# that doxygen will group on one line in the generated HTML documentation.
-
-ENUM_VALUES_PER_LINE = 4
-
-# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
-# generated containing a tree-like index structure (just like the one that
-# is generated for HTML Help). For this to work a browser that supports
-# JavaScript and frames is required (for instance Mozilla, Netscape 4.0+,
-# or Internet explorer 4.0+). Note that for large projects the tree generation
-# can take a very long time. In such cases it is better to disable this feature.
-# Windows users are probably better off using the HTML help feature.
-
-GENERATE_TREEVIEW = NO
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
-# used to set the initial width (in pixels) of the frame in which the tree
-# is shown.
-
-TREEVIEW_WIDTH = 250
-
-#---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
-# generate Latex output.
-
-GENERATE_LATEX = NO
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `latex' will be used as the default path.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked. If left blank `latex' will be used as the default command name.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
-# generate index for LaTeX. If left blank `makeindex' will be used as the
-# default command name.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
-# LaTeX documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_LATEX = NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used
-# by the printer. Possible values are: a4, a4wide, letter, legal and
-# executive. If left blank a4wide will be used.
-
-PAPER_TYPE = a4wide
-
-# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
-# packages that should be included in the LaTeX output.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
-# the generated latex document. The header should contain everything until
-# the first chapter. If it is left blank doxygen will generate a
-# standard header. Notice: only use this tag if you know what you are doing!
-
-LATEX_HEADER =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
-# is prepared for conversion to pdf (using ps2pdf). The pdf file will
-# contain links (just like the HTML output) instead of page references
-# This makes the output suitable for online browsing using a pdf viewer.
-
-PDF_HYPERLINKS = NO
-
-# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
-# plain latex in the generated Makefile. Set this option to YES to get a
-# higher quality PDF documentation.
-
-USE_PDFLATEX = NO
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
-# command to the generated LaTeX files. This will instruct LaTeX to keep
-# running if errors occur, instead of asking the user for help.
-# This option is also used when generating formulas in HTML.
-
-LATEX_BATCHMODE = NO
-
-# If LATEX_HIDE_INDICES is set to YES then doxygen will not
-# include the index chapters (such as File Index, Compound Index, etc.)
-# in the output.
-
-LATEX_HIDE_INDICES = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
-# The RTF output is optimised for Word 97 and may not look very pretty with
-# other RTF readers or editors.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `rtf' will be used as the default path.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
-# RTF documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
-# will contain hyperlink fields. The RTF file will
-# contain links (just like the HTML output) instead of page references.
-# This makes the output suitable for online browsing using WORD or other
-# programs which support those fields.
-# Note: wordpad (write) and others do not support links.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's
-# config file, i.e. a series of assigments. You only have to provide
-# replacements, missing definitions are set to their default value.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an rtf document.
-# Syntax is similar to doxygen's config file.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
-# generate man pages
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `man' will be used as the default path.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to
-# the generated man pages (default is the subroutine's section .3)
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
-# would be unable to find the correct page. The default is NO.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES Doxygen will
-# generate an XML file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `xml' will be used as the default path.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify an XML schema,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify an XML DTD,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_DTD =
-
-
-#---------------------------------------------------------------------------
-# configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
-# generate an AutoGen Definitions (see autogen.sf.net) file
-# that captures the structure of the code including all
-# documentation. Note that this feature is still experimental
-# and incomplete at the moment.
-
-GENERATE_AUTOGEN_DEF = NO
-
- #---------------------------------------------------------------------------
-# configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES Doxygen will
-# generate a Perl module file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
-# the necessary Makefile rules, Perl scripts and LaTeX code to be able
-# to generate PDF and DVI output from the Perl module output.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
-# nicely formatted so it can be parsed by a human reader. This is useful
-# if you want to understand what is going on. On the other hand, if this
-# tag is set to NO the size of the Perl module output will be much smaller
-# and Perl will parse it just the same.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file
-# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
-# This is useful so different doxyrules.make files included by the same
-# Makefile don't overwrite each other's variables.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
-# evaluate all C-preprocessor directives found in the sources and include
-# files.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
-# names in the source code. If set to NO (the default) only conditional
-# compilation will be performed. Macro expansion can be done in a controlled
-# way by setting EXPAND_ONLY_PREDEF to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
-# then the macro expansion is limited to the macros specified with the
-# PREDEFINED and EXPAND_AS_PREDEFINED tags.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
-# in the INCLUDE_PATH (see below) will be search if a #include is found.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by
-# the preprocessor.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will
-# be used.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that
-# are defined before the preprocessor is started (similar to the -D option of
-# gcc). The argument of the tag is a list of macros of the form: name
-# or name=definition (no spaces). If the definition and the = are
-# omitted =1 is assumed.
-
-PREDEFINED =
-
-# If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then
-# this tag can be used to specify a list of macro names that should be expanded.
-# The macro definition that is found in the sources will be used.
-# Use the PREDEFINED tag if you want to use a different macro definition.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
-# doxygen's preprocessor will remove all function-like macros that are alone
-# on a line and do not end with a semicolon. Such function macros are typically
-# used for boiler-plate code, and will confuse the parser if not removed.
-
-SKIP_FUNCTION_MACROS = YES
-
-#---------------------------------------------------------------------------
-# Configuration::addtions related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES tag can be used to specify one or more tagfiles.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create
-# a tag file that is based on the input files it reads.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external classes will be listed
-# in the class index. If set to NO only the inherited external classes
-# will be listed.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
-# in the modules index. If set to NO, only the current project's groups will
-# be listed.
-
-EXTERNAL_GROUPS = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
-# generate a inheritance diagram (in Html, RTF and LaTeX) for classes with base or
-# super classes. Setting the tag to NO turns the diagrams off. Note that this
-# option is superceded by the HAVE_DOT option below. This is only a fallback. It is
-# recommended to install and use dot, since it yield more powerful graphs.
-
-CLASS_DIAGRAMS = YES
-
-# If set to YES, the inheritance and collaboration graphs will hide
-# inheritance and usage relations if the target is undocumented
-# or is not a class.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz, a graph visualization
-# toolkit from AT&T and Lucent Bell Labs. The other options in this section
-# have no effect if this option is set to NO (the default)
-
-HAVE_DOT = NO
-
-# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect inheritance relations. Setting this tag to YES will force the
-# the CLASS_DIAGRAMS tag to NO.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect implementation dependencies (inheritance, containment, and
-# class references variables) of the class with other documented classes.
-
-COLLABORATION_GRAPH = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similiar to the OMG's Unified Modeling
-# Language.
-UML_LOOK = YES
-
-# If set to YES, the inheritance and collaboration graphs will show the
-# relations between templates and their instances.
-
-TEMPLATE_RELATIONS = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
-# tags are set to YES then doxygen will generate a graph for each documented
-# file showing the direct and indirect include dependencies of the file with
-# other documented files.
-
-INCLUDE_GRAPH = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
-# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
-# documented header file showing the documented files that directly or
-# indirectly include this file.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
-# generate a call dependency graph for every global function or class method.
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable call graphs for selected
-# functions only using the \callgraph command.
-
-CALL_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
-# will graphical hierarchy of all classes instead of a textual one.
-
-GRAPHICAL_HIERARCHY = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot. Possible values are gif, jpg, and png
-# If left blank gif will be used.
-
-DOT_IMAGE_FORMAT = png
-
-# The tag DOT_PATH can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found on the path.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the
-# \dotfile command).
-
-DOTFILE_DIRS =
-
-# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
-# (in pixels) of the graphs generated by dot. If a graph becomes larger than
-# this value, doxygen will try to truncate the graph, so that it fits within
-# the specified constraint. Beware that most browsers cannot cope with very
-# large images.
-
-MAX_DOT_GRAPH_WIDTH = 1024
-
-# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
-# (in pixels) of the graphs generated by dot. If a graph becomes larger than
-# this value, doxygen will try to truncate the graph, so that it fits within
-# the specified constraint. Beware that most browsers cannot cope with very
-# large images.
-
-MAX_DOT_GRAPH_HEIGHT = 1024
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
-# graphs generated by dot. A depth value of 3 means that only nodes reachable
-# from the root by following a path via at most 3 edges will be shown. Nodes that
-# lay further from the root node will be omitted. Note that setting this option to
-# 1 or 2 may greatly reduce the computation time needed for large code bases. Also
-# note that a graph may be further truncated if the graph's image dimensions are
-# not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH and MAX_DOT_GRAPH_HEIGHT).
-# If 0 is used for the depth value (the default), the graph is not depth-constrained.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
-# generate a legend page explaining the meaning of the various boxes and
-# arrows in the dot generated graphs.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
-# remove the intermedate dot files that are used to generate
-# the various graphs.
-
-DOT_CLEANUP = YES
-
-#---------------------------------------------------------------------------
-# Configuration::addtions related to the search engine
-#---------------------------------------------------------------------------
-
-# The SEARCHENGINE tag specifies whether or not a search engine should be
-# used. If set to NO the values of all tags below this one will be ignored.
-
-SEARCHENGINE = NO
+++ /dev/null
-# Doxyfile 1.3.4
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project
-#
-# All text after a hash (#) is considered a comment and will be ignored
-# The format is:
-# TAG = value [value, ...]
-# For lists items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (" ")
-
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
-# by quotes) that should identify the project.
-
-PROJECT_NAME = gdcm
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number.
-# This could be handy for archiving the generated documentation or
-# if some version control system is used.
-
-PROJECT_NUMBER =
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
-# base path where the generated documentation will be put.
-# If a relative path is entered, it will be relative to the location
-# where doxygen was started. If left blank the current directory will be used.
-
-OUTPUT_DIRECTORY =
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# The default language is English, other supported languages are:
-# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch,
-# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en
-# (Japanese with English messages), Korean, Norwegian, Polish, Portuguese,
-# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.
-
-OUTPUT_LANGUAGE = English
-
-# This tag can be used to specify the encoding used in the generated output.
-# The encoding is not always determined by the language that is chosen,
-# but also whether or not the output is meant for Windows or non-Windows users.
-# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
-# forces the Windows encoding (this is the default for the Windows binary),
-# whereas setting the tag to NO uses a Unix-style encoding (the default for
-# all platforms other than Windows).
-
-USE_WINDOWS_ENCODING = NO
-
-# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
-# include brief member descriptions after the members that are listed in
-# the file and class documentation (similar to JavaDoc).
-# Set to NO to disable this.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
-# the brief description of a member or function before the detailed description.
-# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-
-REPEAT_BRIEF = YES
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# Doxygen will generate a detailed section even if there is only a brief
-# description.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited
-# members of a class in the documentation of that class as if those members were
-# ordinary class members. Constructors, destructors and assignment operators of
-# the base classes will not be shown.
-
-INLINE_INHERITED_MEMB = YES
-
-# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
-# path before files name in the file list and in the header files. If set
-# to NO the shortest path that makes the file name unique will be used.
-
-FULL_PATH_NAMES = NO
-
-# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
-# can be used to strip a user-defined part of the path. Stripping is
-# only done if one of the specified strings matches the left-hand part of
-# the path. It is allowed to use relative paths in the argument list.
-
-STRIP_FROM_PATH =
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
-# (but less readable) file names. This can be useful is your file systems
-# doesn't support long names like on DOS, Mac, or CD-ROM.
-
-SHORT_NAMES = NO
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
-# will interpret the first line (until the first dot) of a JavaDoc-style
-# comment as the brief description. If set to NO, the JavaDoc
-# comments will behave just like the Qt-style comments (thus requiring an
-# explict @brief command for a brief description.
-
-JAVADOC_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
-# treat a multi-line C++ special comment block (i.e. a block of //! or ///
-# comments) as a brief description. This used to be the default behaviour.
-# The new default is to treat a multi-line C++ comment block as a detailed
-# description. Set this tag to YES if you prefer the old behaviour instead.
-
-MULTILINE_CPP_IS_BRIEF = NO
-
-# If the DETAILS_AT_TOP tag is set to YES then Doxygen
-# will output the detailed description near the top, like JavaDoc.
-# If set to NO, the detailed description appears after the member
-# documentation.
-
-DETAILS_AT_TOP = NO
-
-# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
-# member inherits the documentation from any documented member that it
-# reimplements.
-
-INHERIT_DOCS = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab.
-# Doxygen uses this value to replace tabs by spaces in code fragments.
-
-TAB_SIZE = 8
-
-# This tag can be used to specify a number of aliases that acts
-# as commands in the documentation. An alias has the form "name=value".
-# For example adding "sideeffect=\par Side Effects:\n" will allow you to
-# put the command \sideeffect (or @sideeffect) in the documentation, which
-# will result in a user-defined paragraph with heading "Side Effects:".
-# You can put \n's in the value part of an alias to insert newlines.
-
-ALIASES =
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
-# only. Doxygen will then generate output that is more tailored for C.
-# For instance, some of the names that are used will be different. The list
-# of all members will be omitted, etc.
-
-OPTIMIZE_OUTPUT_FOR_C = NO
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources
-# only. Doxygen will then generate output that is more tailored for Java.
-# For instance, namespaces will be presented as packages, qualified scopes
-# will look different, etc.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
-# the same type (for instance a group of public functions) to be put as a
-# subgroup of that type (e.g. under the Public Functions section). Set it to
-# NO to prevent subgrouping. Alternatively, this can be done per class using
-# the \nosubgrouping command.
-
-SUBGROUPING = YES
-
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available.
-# Private class members and static file members will be hidden unless
-# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
-
-EXTRACT_ALL = NO
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
-# will be included in the documentation.
-
-EXTRACT_PRIVATE = NO
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file
-# will be included in the documentation.
-
-EXTRACT_STATIC = YES
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
-# defined locally in source files will be included in the documentation.
-# If set to NO only classes defined in header files are included.
-
-EXTRACT_LOCAL_CLASSES = NO
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
-# undocumented members of documented classes, files or namespaces.
-# If set to NO (the default) these members will be included in the
-# various overviews, but no documentation section is generated.
-# This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy.
-# If set to NO (the default) these classes will be included in the various
-# overviews. This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_CLASSES = YES
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
-# friend (class|struct|union) declarations.
-# If set to NO (the default) these declarations will be included in the
-# documentation.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
-# documentation blocks found inside the body of a function.
-# If set to NO (the default) these blocks will be appended to the
-# function's detailed documentation block.
-
-HIDE_IN_BODY_DOCS = NO
-
-# The INTERNAL_DOCS tag determines if documentation
-# that is typed after a \internal command is included. If the tag is set
-# to NO (the default) then the documentation will be excluded.
-# Set it to YES to include the internal documentation.
-
-INTERNAL_DOCS = NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
-# file names in lower-case letters. If set to YES upper-case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# users are advised to set this option to NO.
-
-CASE_SENSE_NAMES = YES
-
-# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
-# will show members with their full class and namespace scopes in the
-# documentation. If set to YES the scope will be hidden.
-
-HIDE_SCOPE_NAMES = NO
-
-# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
-# will put a list of the files that are included by a file in the documentation
-# of that file.
-
-SHOW_INCLUDE_FILES = YES
-
-# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
-# is inserted in the documentation for inline members.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
-# will sort the (detailed) documentation of file and class members
-# alphabetically by member name. If set to NO the members will appear in
-# declaration order.
-
-SORT_MEMBER_DOCS = YES
-
-# The GENERATE_TODOLIST tag can be used to enable (YES) or
-# disable (NO) the todo list. This list is created by putting \todo
-# commands in the documentation.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable (YES) or
-# disable (NO) the test list. This list is created by putting \test
-# commands in the documentation.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable (YES) or
-# disable (NO) the bug list. This list is created by putting \bug
-# commands in the documentation.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
-# disable (NO) the deprecated list. This list is created by putting
-# \deprecated commands in the documentation.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# The ENABLED_SECTIONS tag can be used to enable conditional
-# documentation sections, marked by \if sectionname ... \endif.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
-# the initial value of a variable or define consists of for it to appear in
-# the documentation. If the initializer consists of more lines than specified
-# here it will be hidden. Use a value of 0 to hide initializers completely.
-# The appearance of the initializer of individual variables and defines in the
-# documentation can be controlled using \showinitializer or \hideinitializer
-# command in the documentation regardless of this setting.
-
-MAX_INITIALIZER_LINES = 30
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
-# at the bottom of the documentation of classes and structs. If set to YES the
-# list will mention the files that were used to generate the documentation.
-
-SHOW_USED_FILES = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated
-# by doxygen. Possible values are YES and NO. If left blank NO is used.
-
-QUIET = NO
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated by doxygen. Possible values are YES and NO. If left blank
-# NO is used.
-
-WARNINGS = YES
-
-# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
-# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
-# automatically be disabled.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some
-# parameters in a documented function, or documenting parameters that
-# don't exist or using markup commands wrongly.
-
-WARN_IF_DOC_ERROR = YES
-
-# The WARN_FORMAT tag determines the format of the warning messages that
-# doxygen can produce. The string should contain the $file, $line, and $text
-# tags, which will be replaced by the file and line number from which the
-# warning originated and the warning text.
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning
-# and error messages should be written. If left blank the output is written
-# to stderr.
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag can be used to specify the files and/or directories that contain
-# documented source files. You may enter file names like "myfile.cpp" or
-# directories like "/usr/src/myproject". Separate the files or directories
-# with spaces.
-
-INPUT = ../src \
- DoxyPython.txt \
- DoxyMainPageUser.txt \
- DoxyInstallation.txt \
- DoxyPython.txt \
- DoxyIntroduction.txt
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank the following patterns are tested:
-# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp
-# *.h++ *.idl *.odl *.cs *.php *.php3 *.inc
-
-FILE_PATTERNS = *.cxx \
- *.h
-
-# The RECURSIVE tag can be used to turn specify whether or not subdirectories
-# should be searched for input files as well. Possible values are YES and NO.
-# If left blank NO is used.
-
-RECURSIVE = NO
-
-# The EXCLUDE tag can be used to specify files and/or directories that should
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-
-EXCLUDE = ../src/iddcmjpeg.h \
- ../src/gdcmJpeg.cxx
-
-# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories
-# that are symbolic links (a Unix filesystem feature) are excluded from the input.
-
-EXCLUDE_SYMLINKS = NO
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories.
-
-EXCLUDE_PATTERNS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or
-# directories that contain example code fragments that are included (see
-# the \include command).
-
-EXAMPLE_PATH = ../gdcmPython/demo
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank all files are included.
-
-EXAMPLE_PATTERNS =
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude
-# commands irrespective of the value of the RECURSIVE tag.
-# Possible values are YES and NO. If left blank NO is used.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or
-# directories that contain image that are included in the documentation (see
-# the \image command).
-
-IMAGE_PATH =
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command <filter> <input-file>, where <filter>
-# is the value of the INPUT_FILTER tag, and <input-file> is the name of an
-# input file. Doxygen will then use the output that the filter program writes
-# to standard output.
-
-INPUT_FILTER =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER) will be used to filter the input files when producing source
-# files to browse (i.e. when SOURCE_BROWSER is set to YES).
-
-FILTER_SOURCE_FILES = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will
-# be generated. Documented entities will be cross-referenced with these sources.
-
-SOURCE_BROWSER = YES
-
-# Setting the INLINE_SOURCES tag to YES will include the body
-# of functions and classes directly in the documentation.
-
-INLINE_SOURCES = YES
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the REFERENCED_BY_RELATION tag is set to YES (the default)
-# then for each documented function all documented
-# functions referencing it will be listed.
-
-REFERENCED_BY_RELATION = YES
-
-# If the REFERENCES_RELATION tag is set to YES (the default)
-# then for each documented function all documented entities
-# called/used by that function will be listed.
-
-REFERENCES_RELATION = YES
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
-# will generate a verbatim copy of the header file for each class for
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
-# of all compounds will be generated. Enable this if the project
-# contains a lot of classes, structs, unions or interfaces.
-
-ALPHABETICAL_INDEX = YES
-
-# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
-# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
-# in which this list will be split (can be a number in the range [1..20])
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all
-# classes will be put under the same header in the alphabetical index.
-# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
-# should be ignored while generating the index headers.
-
-IGNORE_PREFIX =
-
-#---------------------------------------------------------------------------
-# configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
-# generate HTML output.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `html' will be used as the default path.
-
-HTML_OUTPUT = html.user
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
-# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
-# doxygen will generate files with .html extension.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a personal HTML header for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard header.
-
-HTML_HEADER =
-
-# The HTML_FOOTER tag can be used to specify a personal HTML footer for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard footer.
-
-HTML_FOOTER =
-
-# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
-# style sheet that is used by each HTML page. It can be used to
-# fine-tune the look of the HTML output. If the tag is left blank doxygen
-# will generate a default style sheet
-
-HTML_STYLESHEET =
-
-# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
-# files or namespaces will be aligned in HTML using tables. If set to
-# NO a bullet list will be used.
-
-HTML_ALIGN_MEMBERS = YES
-
-# If the GENERATE_HTMLHELP tag is set to YES, additional index files
-# will be generated that can be used as input for tools like the
-# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
-# of the generated HTML documentation.
-
-GENERATE_HTMLHELP = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
-# be used to specify the file name of the resulting .chm file. You
-# can add a path in front of the file if the result should not be
-# written to the html output dir.
-
-CHM_FILE =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
-# be used to specify the location (absolute path including file name) of
-# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
-# the HTML help compiler on the generated index.hhp.
-
-HHC_LOCATION =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
-# controls if a separate .chi index file is generated (YES) or that
-# it should be included in the master .chm file (NO).
-
-GENERATE_CHI = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
-# controls whether a binary table of contents is generated (YES) or a
-# normal table of contents (NO) in the .chm file.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members
-# to the contents of the HTML help documentation and to the tree view.
-
-TOC_EXPAND = NO
-
-# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
-# top of each HTML page. The value NO (the default) enables the index and
-# the value YES disables it.
-
-DISABLE_INDEX = NO
-
-# This tag can be used to set the number of enum values (range [1..20])
-# that doxygen will group on one line in the generated HTML documentation.
-
-ENUM_VALUES_PER_LINE = 4
-
-# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
-# generated containing a tree-like index structure (just like the one that
-# is generated for HTML Help). For this to work a browser that supports
-# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
-# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
-# probably better off using the HTML help feature.
-
-GENERATE_TREEVIEW = NO
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
-# used to set the initial width (in pixels) of the frame in which the tree
-# is shown.
-
-TREEVIEW_WIDTH = 250
-
-#---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
-# generate Latex output.
-
-GENERATE_LATEX = NO
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `latex' will be used as the default path.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked. If left blank `latex' will be used as the default command name.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
-# generate index for LaTeX. If left blank `makeindex' will be used as the
-# default command name.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
-# LaTeX documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_LATEX = NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used
-# by the printer. Possible values are: a4, a4wide, letter, legal and
-# executive. If left blank a4wide will be used.
-
-PAPER_TYPE = a4wide
-
-# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
-# packages that should be included in the LaTeX output.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
-# the generated latex document. The header should contain everything until
-# the first chapter. If it is left blank doxygen will generate a
-# standard header. Notice: only use this tag if you know what you are doing!
-
-LATEX_HEADER =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
-# is prepared for conversion to pdf (using ps2pdf). The pdf file will
-# contain links (just like the HTML output) instead of page references
-# This makes the output suitable for online browsing using a pdf viewer.
-
-PDF_HYPERLINKS = NO
-
-# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
-# plain latex in the generated Makefile. Set this option to YES to get a
-# higher quality PDF documentation.
-
-USE_PDFLATEX = NO
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
-# command to the generated LaTeX files. This will instruct LaTeX to keep
-# running if errors occur, instead of asking the user for help.
-# This option is also used when generating formulas in HTML.
-
-LATEX_BATCHMODE = NO
-
-# If LATEX_HIDE_INDICES is set to YES then doxygen will not
-# include the index chapters (such as File Index, Compound Index, etc.)
-# in the output.
-
-LATEX_HIDE_INDICES = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
-# The RTF output is optimised for Word 97 and may not look very pretty with
-# other RTF readers or editors.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `rtf' will be used as the default path.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
-# RTF documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
-# will contain hyperlink fields. The RTF file will
-# contain links (just like the HTML output) instead of page references.
-# This makes the output suitable for online browsing using WORD or other
-# programs which support those fields.
-# Note: wordpad (write) and others do not support links.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's
-# config file, i.e. a series of assigments. You only have to provide
-# replacements, missing definitions are set to their default value.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an rtf document.
-# Syntax is similar to doxygen's config file.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
-# generate man pages
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `man' will be used as the default path.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to
-# the generated man pages (default is the subroutine's section .3)
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
-# would be unable to find the correct page. The default is NO.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES Doxygen will
-# generate an XML file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `xml' will be used as the default path.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify an XML schema,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify an XML DTD,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_DTD =
-
-#---------------------------------------------------------------------------
-# configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
-# generate an AutoGen Definitions (see autogen.sf.net) file
-# that captures the structure of the code including all
-# documentation. Note that this feature is still experimental
-# and incomplete at the moment.
-
-GENERATE_AUTOGEN_DEF = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES Doxygen will
-# generate a Perl module file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
-# the necessary Makefile rules, Perl scripts and LaTeX code to be able
-# to generate PDF and DVI output from the Perl module output.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
-# nicely formatted so it can be parsed by a human reader. This is useful
-# if you want to understand what is going on. On the other hand, if this
-# tag is set to NO the size of the Perl module output will be much smaller
-# and Perl will parse it just the same.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file
-# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
-# This is useful so different doxyrules.make files included by the same
-# Makefile don't overwrite each other's variables.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
-# evaluate all C-preprocessor directives found in the sources and include
-# files.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
-# names in the source code. If set to NO (the default) only conditional
-# compilation will be performed. Macro expansion can be done in a controlled
-# way by setting EXPAND_ONLY_PREDEF to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
-# then the macro expansion is limited to the macros specified with the
-# PREDEFINED and EXPAND_AS_PREDEFINED tags.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
-# in the INCLUDE_PATH (see below) will be search if a #include is found.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by
-# the preprocessor.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will
-# be used.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that
-# are defined before the preprocessor is started (similar to the -D option of
-# gcc). The argument of the tag is a list of macros of the form: name
-# or name=definition (no spaces). If the definition and the = are
-# omitted =1 is assumed.
-
-PREDEFINED =
-
-# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
-# this tag can be used to specify a list of macro names that should be expanded.
-# The macro definition that is found in the sources will be used.
-# Use the PREDEFINED tag if you want to use a different macro definition.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
-# doxygen's preprocessor will remove all function-like macros that are alone
-# on a line, have an all uppercase name, and do not end with a semicolon. Such
-# function macros are typically used for boiler-plate code, and will confuse the
-# parser if not removed.
-
-SKIP_FUNCTION_MACROS = YES
-
-#---------------------------------------------------------------------------
-# Configuration::addtions related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES option can be used to specify one or more tagfiles.
-# Optionally an initial location of the external documentation
-# can be added for each tagfile. The format of a tag file without
-# this location is as follows:
-# TAGFILES = file1 file2 ...
-# Adding location for the tag files is done as follows:
-# TAGFILES = file1=loc1 "file2 = loc2" ...
-# where "loc1" and "loc2" can be relative or absolute paths or
-# URLs. If a location is present for each tag, the installdox tool
-# does not have to be run to correct the links.
-# Note that each tag file must have a unique name
-# (where the name does NOT include the path)
-# If a tag file is not located in the directory in which doxygen
-# is run, you must also specify the path to the tagfile here.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create
-# a tag file that is based on the input files it reads.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external classes will be listed
-# in the class index. If set to NO only the inherited external classes
-# will be listed.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
-# in the modules index. If set to NO, only the current project's groups will
-# be listed.
-
-EXTERNAL_GROUPS = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
-# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base or
-# super classes. Setting the tag to NO turns the diagrams off. Note that this
-# option is superceded by the HAVE_DOT option below. This is only a fallback. It is
-# recommended to install and use dot, since it yields more powerful graphs.
-
-CLASS_DIAGRAMS = YES
-
-# If set to YES, the inheritance and collaboration graphs will hide
-# inheritance and usage relations if the target is undocumented
-# or is not a class.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz, a graph visualization
-# toolkit from AT&T and Lucent Bell Labs. The other options in this section
-# have no effect if this option is set to NO (the default)
-
-HAVE_DOT = NO
-
-# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect inheritance relations. Setting this tag to YES will force the
-# the CLASS_DIAGRAMS tag to NO.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect implementation dependencies (inheritance, containment, and
-# class references variables) of the class with other documented classes.
-
-COLLABORATION_GRAPH = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similiar to the OMG's Unified Modeling
-# Language.
-
-UML_LOOK = NO
-
-# If set to YES, the inheritance and collaboration graphs will show the
-# relations between templates and their instances.
-
-TEMPLATE_RELATIONS = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
-# tags are set to YES then doxygen will generate a graph for each documented
-# file showing the direct and indirect include dependencies of the file with
-# other documented files.
-
-INCLUDE_GRAPH = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
-# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
-# documented header file showing the documented files that directly or
-# indirectly include this file.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
-# generate a call dependency graph for every global function or class method.
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable call graphs for selected
-# functions only using the \callgraph command.
-
-CALL_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
-# will graphical hierarchy of all classes instead of a textual one.
-
-GRAPHICAL_HIERARCHY = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot. Possible values are png, jpg, or gif
-# If left blank png will be used.
-
-DOT_IMAGE_FORMAT = png
-
-# The tag DOT_PATH can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found on the path.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the
-# \dotfile command).
-
-DOTFILE_DIRS =
-
-# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
-# (in pixels) of the graphs generated by dot. If a graph becomes larger than
-# this value, doxygen will try to truncate the graph, so that it fits within
-# the specified constraint. Beware that most browsers cannot cope with very
-# large images.
-
-MAX_DOT_GRAPH_WIDTH = 1024
-
-# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
-# (in pixels) of the graphs generated by dot. If a graph becomes larger than
-# this value, doxygen will try to truncate the graph, so that it fits within
-# the specified constraint. Beware that most browsers cannot cope with very
-# large images.
-
-MAX_DOT_GRAPH_HEIGHT = 1024
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
-# graphs generated by dot. A depth value of 3 means that only nodes reachable
-# from the root by following a path via at most 3 edges will be shown. Nodes that
-# lay further from the root node will be omitted. Note that setting this option to
-# 1 or 2 may greatly reduce the computation time needed for large code bases. Also
-# note that a graph may be further truncated if the graph's image dimensions are
-# not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH and MAX_DOT_GRAPH_HEIGHT).
-# If 0 is used for the depth value (the default), the graph is not depth-constrained.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
-# generate a legend page explaining the meaning of the various boxes and
-# arrows in the dot generated graphs.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
-# remove the intermediate dot files that are used to generate
-# the various graphs.
-
-DOT_CLEANUP = YES
-
-#---------------------------------------------------------------------------
-# Configuration::addtions related to the search engine
-#---------------------------------------------------------------------------
-
-# The SEARCHENGINE tag specifies whether or not a search engine should be
-# used. If set to NO the values of all tags below this one will be ignored.
-
-SEARCHENGINE = NO
-Gdcm is copyrighted as an open-source, Berkely-style license. It allows
+Gdcm is copyrighted as an open-source, Berkeley-style license. It allows
unrestricted use, including use in commercial products. The complete
copyright is shown below.
+++ /dev/null
-HTML_DIR=$(datadir)/gdcm/html
-TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE)
-
-EXTRA_DIST = \
- DoxyfileDeveloppers \
- DoxyfileUsers \
- DoxyDevelInstal.txt \
- DoxyIntroduction.txt \
- DoxyPython.txt \
- DoxyInstallation.txt \
- DoxyMainPage.txt
-
-all-local: html.developper/index.html html.user/index.html
-
-if ENABLE_DOXYGEN
-html.developper/index.html: DoxyfileDeveloppers
- doxygen DoxyfileDeveloppers
-html.user/index.html: DoxyfileUsers
- doxygen DoxyfileUsers
-else
-html.developper/index.html:
-html.user/index.html:
-endif
-
-clean-local:
- rm -f *~ *.bak
- rm -rf man latex html.developper html.user rtf
-
-install-data-local: html.developper html.user
- $(mkinstalldirs) $(DESTDIR)$(TARGET_DIR)
- (installfiles=`echo html.developper/*`; \
- if test "$$installfiles" = 'html.developper/*'; \
- then echo '-- Nothing to install' ; \
- else \
- for i in $$installfiles; do \
- echo '-- Installing '$$i ; \
- $(INSTALL_DATA) $$i $(DESTDIR)$(TARGET_DIR); \
- done; \
- fi)
-
-dist-hook:
- rm -rf $(distdir)/html.developper $(distdir)/html.user
-
-.PHONY : html.developper html.user latex man
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>Gdcm Developpers</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>Gdcm coding style (and other religious/agnostic beliefs)</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+<PRE>
+* Introduction:
+ The following coding style intends to ease the work of developpers
+ themselves but also of users who will study, maintain, fix, and extend
+ the code. Any bread crumbs that you can drop in the way of explanatory
+ names and comments will go a long way towards helping other readers and
+ developers.
+ Keep in mind that to a large extent the structure of code directly
+ expresses its implementation.
+
+* Language:
+ - C++ (for the kernel) and Python (for the wrappers).
+ - all the names (variables, members, methods, functions) and comments
+ should be based on English. Documentation, guides, web site and other
+ informations should be in English.
+ Make sure you use correct (basic) English and complete, grammatically
+ correct sentences for comments and documentation.
+
+* General layout:
+ - Each line of code should take no more than 79 characters. Break the code
+ across multiple lines as necessary.
+ - Methods and functions should keep a reasonable number of lines when
+ possible (a typical editor displays 50 lines). Avoid code duplication.
+ Always prefer creating a new method or function to duplication.
+ A high indentation level generally suggests the need for a new
+ method or function.
+ - All the code should be properly indented. The appropriate indentation
+ level is three spaces for each level of indentation. DO NOT USE TABS.
+ Set up your editor to insert spaces. Using tabs may look good in your
+ editor but will wreak havoc in others, or in external tools (e.g. side
+ by side diffs).
+ - The declaration of variables within classes, methods, and functions
+ should be one declaration per line. Provide them with default values
+ and don't rely on compilers for default initialization.
+
+* Naming conventions:
+ - Generalities:
+ In general, names are constructued by using case change to indicate
+ separate words, as in ImageDataSize (standing for "image data size").
+ Underscores are not used. Variable names are chosen carefully with the
+ intention to convey the meaning behind the code. Names are generally
+ spelled out; use of abbreviations is discouraged.
+ [Note: abbreviation are allowable when in common use, and should be in
+ uppercase as in LUT or RGBA.]
+ While this does result in long names, it self-documents the code.
+ - Naming Files:
+ Files should have the same name as the class, with a "gdcm" prepended.
+ Header files are named .h, while implementation files are named either
+ .cxx or .txx, depending on whether they are implementations of templated
+ classes. For example, the class gdcm::Document is declared and defined
+ in the files gdcmDocument.h and gdcmDocument.cxx.
+ - Naming Class Data Members, Methods, and Functions:
+ Class data members are named beginning with a capital letter as in
+ GroupPixel.
+ Global functions and class methods, either static or class members, are
+ named beginning with a capital letter, as in GetImageDataSize().
+ - Naming Local Variables:
+ Local variables begin in lowercase. There is more flexibility in the
+ naming of local variables although they still should convey some
+ semantics.
+
+* Classes:
+ - Don't use the inline keyword when defining an inline function
+ within a class definition.
+ - As stated in the "Naming conventions" section, class data members
+ are named beginning with a capital letter as in GroupPixel.
+ But the parameter names of method should be named with a lowercase
+ letter (in order to distinguish at a glance data members, from parameters
+ and also to avoid potential collisions with data members):
+ void A::SetGroupPixel( int groupPixel )
+ {
+ GroupPixel = groupPixel;
+ }
+ - Do not repeat the virtual keyword when overriding virtual base methods
+ in declaration of subclasses:
+ class A
+ {
+ virtual void foo(...);
+ };
+ class B: public A
+ {
+ void foo(...); // and not: virtual void foo(...);
+ };
+ - The public, protected, private declarations should be at the
+ same indent level as the class. Use
+ class A
+ {
+ private:
+ void foo(...);
+ public:
+ void bar(...);
+ };
+ - Method and functions devoided of arguments should not use the void
+ notation. Use
+ SomeType Header::GetPixelData()
+ and not
+ SomeType Header::GetPixelData(void).
+
+* Use of braces:
+ - Braces must be used to delimit the scope of an if, for, while, switch, or
+ other control structure. Braces are placed on a line by themselves, and
+ at the same indentation level as the control structure to which they
+ belong:
+ for (i=0; * i<3; i++)
+ {
+ ...
+ }
+ or when using an if:
+ if ( condition )
+ {
+ ...
+ }
+ else if ( other condition )
+ {
+ ...
+ }
+ else
+ {
+ ....
+ }
+ You can choose to use braces on a line with a code block when
+ the block consists of a single line:
+ if ( condition ) { foo=1; }
+ else if ( condition2 ) { foo=3; }
+ else { return; }
+ or
+ for (i=0; i<3; ++i) {x[i]=0.0;}
+ Methods and functions should follow the same usage of braces:
+ void File::ParsePixelData()
+ {
+ ...
+ }
+
+* Special layout:
+ - Avoid code mixed with comments on a single line. Instead, prepend the
+ logical blocks of code with the concerned comments.
+ - Use parantheses around conditions e.g. with an if statement:
+ if ( someLocalVariable == 2 ) { ... }
+ - Add spaces around parantheses, or braces. Use
+ if ( someLocalVariable == 2 ) { ClassMenber += 1; }
+ and not
+ if (someLocalVariable == 2) {ClassMenber += 1;}
+ - Add spaces around each side of the assignement operator, and
+ around binary operators used in boolean expression. Use
+ someLocalVariable = ClassMember * 2;
+ if ( someLocalVariable == 2 || ClassMember == 2 ) ...
+ and not
+ someLocalVariable=ClassMember*2;
+ if ( someLocalVariable==2||ClassMember==2 ) ...
+
+* Miscelaneous:
+ - Don't use underscores. Don't use tabs. Don't use control characters
+ like ^M. Anyhow, cvs is configured to reject such commits.
+ - Comments should be in C++ style ("// ...", two slashes, per line). Don't
+ use C style comments ("/* ... */").
+ - The last line of a file should terminate with "\n".
+ - Returned arguments of methods and functions should not be wrapped with
+ parantheses. Use
+ return iter->second;
+ but do not use
+ return ( iter->second );
+
+* Debugging and Verbose modes:
+ Never use std::cout. Instead use the gdcmDebug class through the
+ global instance dbg. Example:
+ #include "gdcmDebug.h"
+ ...
+ {
+ dbg.Verbose(3, "Local function name: entering.");
+ ...
+ }
+ will send the message to std::cout when dbg.Debug() is called
+ in your main.
+
+* Documentation:
+ The Doxygen open-source system is used to generate on-line documentation.
+ Doxygen requires the embedding of simple comments in the code which is in
+ turn extracted and formatted into documentation. See
+ http://www.stack.nl/ dimitri/doxygen/
+ for more information about Doxygen.
+ - Documenting a class:
+ Classes should be documented using the class and brief doxygen commands,
+ followed by the detailed class description:
+ /**
+ * \class Header
+ * \brief Header acts as container of Dicom elements of an image.
+ *
+ * Detailed description of the class is provided here
+ * ...
+ */
+ The key here is that the comment starts with /**, each subsequent line has
+ an aligned *, and the comment block terminates with a */.
+ - Documenting class members and inline methods:
+ All the members and the inline methods should be documented within
+ the class declaration as shown in the following example:
+ class Header
+ {
+ /// True when parsing was succesfull. False otherwise.
+ bool Readable = false;
+
+ /// \brief The number of lines of the image as interpreted from
+ /// the various elements encountered at header parsing.
+ int NumberOfLines = -1;
+
+ /// Predicate implemented as accessor around \ref Readable.
+ bool IsReadable() { return Readable; }
+ };
+ - Documenting a Method:
+ Methods should be documented using the following comment block style
+ as shown in the following example:
+
+ /**
+ * \brief Within the Dicom Elements (parsed with the public and private
+ * dictionaries), look for the element value representation of
+ * a given tag.
+ * @param group Group number of the searched tag.
+ * @param element Element number of the searched tag.
+ * @return Corresponding element value representation when it exists,
+ * and the string "gdcm::Unfound" otherwise.
+ */
+ std::string Document::GetEntryByNumber(guint16 group, guint16 element)
+ {
+ ...
+ }
+
+* External includes and C style:
+ - Only the C++ standard library and the STL includes should be used.
+ When including don't use the .h extension (use #include <iostream>
+ instead of #include <iostream.h>).
+ - Don't use the C standard library. Don't include stdio.h, ctype.h...
+ Don't use printf(), sprinf(), FILE*...
+ - Don't use the NULL notation (either as macro, or as const int NULL=0).
+ A pointer that doesn't refer to an object should simply be defined as
+ DataPointer* MyDataPointer = 0;
+
+* Basic types:
+ - Assume T is a given type. When declaring or defining with the
+ "pointer to T" notation, the * character must be adjacent to
+ the type and not the variable. That is use
+ T* foo = 0;
+ and not
+ T *foo = 0;
+ - Always define a typedef for a new type and be consistent in usage.
+ Use
+ typedef Header* HeaderPointer;
+ HeaderPointer MyHeaderPointer;
+ - One notorious counter example for non using C style inclusion concerns
+ exact-width integers (since there seem to be no equivalent for C++).
+ When using exact-width integers use the typedef names defined by
+ the Basic ISO C99: 7.18 Integer types i.e.
+ int8_t int16_t int32_t int64_t (signed integers)
+ and
+ uint8_t uint16_t uint32_t uint64_t (unsigned integers).
+ Conversion table is then:
+ unsigned char -> uint8_t;
+ unsigned short -> uint16_t;
+ unsigned int -> uint32_t;
+ unsigned long -> uint32_t;
+ unsigned long long -> uint64_t;
+ (signed) char -> int8_t;
+ short -> int16_t;
+ int -> int32_t;
+ long -> int32_t;
+ long long -> int64_t;
+ Hence do not use declarations like "unsigned int".
+ With g++, accessing those typedef is achieved by the following
+ #include <stdint.h>
+</PRE>
+
+
+<!#######################################################################>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>Gdcm Developpers</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>Gdcm Developpers</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+First you should be familiar on how to
+<A HREF="Installation.html">recompile, install and test</A>
+gdcm from the
+<A HREF="Cvs.html">sources obtained with cvs</A>.
+<BR>
+<!##############################>
+Please adopt the
+<A HREF="CodingStyle.html"><B>coding style</B></A>.
+<BR>
+<!##############################>
+<H3>CVS policy</H3>
+<UL>
+<LI>All the commits should be atomic. They must preserve the compilation
+ in order to prevent checkouts with broken code.
+</LI>
+<LI> All the commits must correspond to a state of the code where ctest
+ runs and has no failing subtest. Always run ctest before commiting.
+ <BR>
+ <B>Notes</B>:
+ <UL>
+ <LI> you can start ctest in verbose mode through the command
+ <TT>ctest -V >& log</TT>
+ </LI>
+ <LI> you can start a single test through ctest with
+ ctest -R FailingTestName -V >& log
+ </LI>
+ </UL>
+</LI>
+</UL>
+
+<!##############################>
+<H3>Compiler flags policy</H3>
+When working with gcc please use the following flags when
+configuring the cmake variable <TT>CMAKE_CXX_FLAGS</TT>
+<BR>
+<TT>-g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter
+ -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated
+ -Woverloaded-virtual
+</TT>
+
+<!##############################>
+<H3>Sending the result to kitware's dashboard (optional)</H3>
+Use <TT>ctest -D Experimental</TT>.
+<BR>
+The results should appear in
+<A HREF="http://public.kitware.com/dashboard.php?name=public">
+ Kitware's dashboard</A>
+under the name of your machine (uname). 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.
+
+
+<!#######################################################################>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>GdcmPython</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>Python wrappers for gdcm</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+<!#######################################################################>
+<H2>Working with Python</H2>
+<UL>
+<LI><code>cd GDCM_HOME</code>
+</LI>
+<LI><code>export PYTHONPATH=`pwd`</code>
+</LI>
+<LI><code>cd gdcmPython</code>
+</LI>
+<LI><code>ln -s .libs/pygdcm.so _gdcm.so</code>
+ <BR> (this is because automake doesn't allow the building of libraries
+ whose name starts with an underscore. Since we need the
+ wrapper library to be named _gdcm [because swig automaticatily uses
+ this name when building the shadow classes], automake generates
+ pygdcm.so and at install stage stage renames it to _gdcm.so).
+</LI>
+<LI>You can then use gdcmPython for manual test/demos
+ <OL>
+ <LI><code>cd GDCM_HOME/gdcmPython/demo</code>
+ </LI>
+ <LI><code>python PrintHeader.py</code>
+ </LI>
+ </OL>
+</LI>
+</UL>
+
+<!#######################################################################>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+<PRE>
+ 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 *").
+</PRE>
+
+<!#######################################################################>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</BODY>
+</HTML>
<!#######################################################################>
<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
<H2>Packaged distributions of gdcm last stable
- <A HREF="News.html#NewsVersion0_4">version 0.4</A>
+ <A HREF="News.html#NewsVersion0_4">version 0.4</A>
+ (February 6 2004)
</H2>
Please refer to the
<TT>cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co
-r Version0_4 gdcm</TT>.
+<!#######################################################################>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+<H2>Packaged distributions of intermediate version of Apr 20 2004 </H2>
+
+<B>RPM for rh9 and fc1</B> (sources and binaries).
+<UL>
+ <LI> for <A HREF="../GdcmPackages/rpms/rh9">RedHat 9</A>
+ </LI>
+ <LI> for <A HREF="rpms/fc1">Fedora Core 1</A>
+ </LI>
+</UL>
<!#######################################################################>
<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
<UL>
<LI>
- <A HREF="DownloadVersion0_3.html">version 0.3</A>
+ <A HREF="DownloadVersion0_3.html">version 0.3</A>,
+</LI>
<LI>
+ <A HREF="DownloadVersion0_1.html">version 0.1</A>.
+</LI>
</UL>
<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>Gdcm Download Version0_1</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>gdcm download of version 0.1</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+
+<UL>
+
+<!###############################>
+<LI><B>Sources</B>
+ <UL>
+ <LI>For
+ <A HREF="html.developper/DoxyPythonComplete.html">gdcmPython</A>
+ a compressed tarball is available
+ <A HREF="../GdcmPackages/bin20030401/gdcmPython-0.1.tar.gz">
+ gdcmPython-0.1.tar.gz</A>.
+ </LI>
+ <LI> The full sources of version 0.1 can be retrieved
+ through cvs (see <A HREF="Cvs.html">gdcm cvs access</A>)
+ with the cvs tag <B>April2003</B> e.g.
+ <BR>
+ <TT>cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co
+ -r April2003 gdcm
+ </TT>.
+ </LI>
+ </UL>
+</LI>
+
+<!###############################>
+<LI><B>Win32</B>
+ <IMG src="Icons/os-windows.gif" alt="win95 logo" nosave height=32 width=32>
+ <UL>
+ <LI>Sorry but the Kernel Win32 packaging starts at version 0.4.
+ </LI>
+ <LI> Windoze self installer of gdcmPython
+ <A HREF="../GdcmPackages/bin20030401/gdcmPython-0.1.win32-py2.2.exe">
+ gdcmPython-0.1.win32-py2.2.exe</A> for Win32 (expects Python2.2.x).
+ </LI>
+ </UL>
+</LI>
+
+<!###############################>
+<LI> <B>GNU/Linux RPM</B> packages
+ <IMG src="Icons/os-linux.gif" alt="win95 logo" nosave height=32 width=32>
+ <UL>
+ <LI><B>Gdcm kernel</B>
+ Sorry but the Kernel rpm packaging (both sources and binaries)
+ starts at
+ <A HREF="DownloadVersion0_3.html">version 0.3</A>.
+ </LI>
+ <LI><B>GdcmPython (source and binaries)</B>
+ <UL>
+ <LI>Source rpm
+ <A HREF="../GdcmPackages/bin20030401/gdcmPython-0.1-1.src.rpm">
+ gdcmPython-0.1-1.src.rpm</A>,
+ requires swig 1.3.17.x [
+ <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.i386.rpm">
+ swig13-1.3.17-1.i386.rpm</A>,
+ <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.src.rpm">
+ swig13-1.3.17-1.src.rpm</A>]
+ <LI>Binary rpm
+ <A HREF="../GdcmPackages/bin20030401/gdcmPython-0.1-1.i386.rpm">
+ gdcmPython-0.1-1.i386.rpm</A>,
+ (depends on Python2.2.x)
+ </UL>
+ </LI>
+ </UL>
+</UL>
+
+
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>Gdcm Download Version0_3</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>gdcm download of version 0.3</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+Please refer to the
+ <A HREF="News.html#NewsVersion0_3">News on version 0.3</A>
+for more information on the features of this release
+
+<UL>
+ <!###############################>
+ <LI><B>Win32</B>
+ <IMG src="Icons/os-windows.gif" alt="win95 logo"
+ nosave height=32 width=32>
+ <UL>
+ <LI> Sorry but the Kernel Win32 packaging starts at version 0.4.
+ </LI>
+ <LI>Zipped archive or sources
+ <A HREF="../GdcmPackages/bin20030708/gdcmPython-0.3.zip">
+ gdcmPython-0.3.zip</A>,
+ </LI>
+ <LI> Windoze self installer of gdcmPython
+ <A HREF="../GdcmPackages/bin20030708/gdcmPython-0.3.win32-py2.2.exe">
+ gdcmPython-0.3.win32-py2.2.exe</A> for Win32 (expects Python2.2.x).
+ </LI>
+ </UL>
+ </LI>
+
+ <!###############################>
+ <LI> <B>GNU/Linux RPM</B> packages
+ <IMG src="Icons/os-linux.gif" alt="win95 logo"
+ nosave height=32 width=32>
+ <UL>
+ <LI><B>Gdcm kernel</B>
+ <UL>
+ <LI>Sources in a compressed tarball:
+ <A HREF="../GdcmPackages/bin20030708/gdcm-0.3.0.tar.gz">
+ gdcm-0.3.0.tar.gz</A>.
+ </LI>
+ <LI>Source rpm
+ <A HREF="../GdcmPackages/bin20030708/gdcm-0.3.0-1.src.rpm">
+ gdcm-0.3.0-1.src.rpm</A>,
+ which requires swig 1.3.17.x [
+ <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.i386.rpm">
+ swig13-1.3.17-1.i386.rpm</A>,
+ <A HREF="http://www.creatis.insa-lyon.fr/rpm/swig13-1.3.17-1.src.rpm">
+ swig13-1.3.17-1.src.rpm</A>]
+ </LI>
+ <LI>Binary rpm
+ <A HREF="../GdcmPackages/bin20030708/gdcm-0.3.0-1.i386.rpm">
+ gdcm-0.3.0-1.i386.rpm</A>.
+ </LI>
+ </UL>
+ </LI>
+ <LI><B>GdcmPython (source and binaries)</B>
+ <UL>
+ <LI>Sources in a compressed tarball:
+ <A HREF="../GdcmPackages/bin20030708/gdcmPython-0.3.tar.gz">
+ gdcmPython-0.3.tar.gz</A>.
+ <LI>Source rpm
+ <A HREF="../GdcmPackages/bin20030708/gdcmPython-0.3-1.src.rpm">
+ gdcmPython-0.3-1.src.rpm</A>,
+ <LI>Binary rpm
+ <A HREF="../GdcmPackages/bin20030708/gdcmPython-0.3-1.i386.rpm">
+ gdcmPython-0.3-1.i386.rpm</A>,
+ (depends on Python2.2.x)
+ </UL>
+ </LI>
+ </UL>
+</UL>
+
+<B>Note:</B> The corresponding sources can be retrieved through cvs (see
+<A HREF="Cvs.html">gdcm cvs access</A>)
+with the cvs tag <B>Version0_3</B> e.g.
+<BR>
+<TT>cvs -d:pserver:frog@cvs.creatis.insa-lyon.fr:2402/cvs/public co
+ -r Version0_3 gdcm</TT>.
+
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</BODY>
+</HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML>
+<HEAD>
+ <META http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <TITLE>GdcmData access with cvs</TITLE>
+</HEAD>
+
+<BODY>
+
+<!#######################################################################>
+<H1>Using CVS for retrieval of gdcmData</H1>
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+<!#######################################################################>
+To learn more about CVS and to get the CVS programs, please refer to the
+<A HREF="http://www.cvshome.org/index.html">CVS Home</A>.
+
+<UL>
+ <LI><B>GENERAL</B>
+ <UL>
+ <LI>Repository server:
+ <tt>:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public</tt>
+ <LI>Password is <TT>anonymous</TT>
+ </UL>
+ <LI><B>Linux</B>
+ <IMG src="Icons/os-linux.gif" alt="tux logo" nosave height=32 width=32>
+ (if your shell is not bash then please adapt the syntax)
+ <UL>
+ <LI><tt>export CVSROOT=:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public</tt>
+ <LI><tt>cvs login</tt> (at prompt <TT>CVS password</TT> answer <TT>anonymous</TT>)
+ <LI><tt>cvs checkout gdcmData</tt>
+ </UL>
+ <LI><B>Windows (WinCVS 1.2)</B>
+ <IMG src="Icons/os-windows.gif" alt="win95 logo" nosave height=32 width=32>
+ <UL>
+ <LI>Tag general - CVSROOT :
+ <tt>:pserver:anonymous@cvs.creatis.insa-lyon.fr:/cvs/public</tt>
+ <LI>Tag Ports - check 'For pserver' : <tt>2402</tt>
+ </UL>
+</UL>
+
+<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
+
+</body>
+</html>
+
<HR size="1"><ADDRESS style="align: right;"></ADDRESS>
<!###################################>
-<H2> Requirements</H2>
+<H2> <A CLASS="anchor" NAME="gdcmRequirements">Requirements</A></H2>
<UL>
<LI> For the core C++ library you shall need a C++ compiler with the
"list" and "map" STL containers.
</UL>
</UL>
+<!###################################>
+<H2> GNU/Linux walkthrough for the impatient bash user</H2>
+<UL>
+ <LI><TT>cd SOMEWHERE</TT>
+ </LI>
+ <LI><TT>
+ export CVSROOT=:pserver:anonymous@cvs.creatis.insa-lyon.fr:2402/cvs/public
+ </TT>
+ </LI>
+ <LI><TT>cvs login</TT> (at prompt <TT>CVS password</TT>
+ answer with <TT>anonymous</TT>)
+ </LI>
+ <LI><TT>cvs co gdcm</TT>
+ </LI>
+ <LI>[Optional, for test suite]
+ <TT>cvs co gdcmData</TT>
+ </LI>
+ <LI><TT>mkdir gdcmInstall</TT>
+ </LI>
+ <LI><TT>mkdir gdcmBin</TT>
+ </LI>
+ <LI><TT>cd gdcmBin</TT>
+ </LI>
+ <LI><TT>ccmake ../gdcm</TT>
+ <UL>
+ <LI>
+ Toggle and adjust the required options and parameters
+ <BR>
+ (see below for more info)
+ </LI>
+ <LI> hit <TT>c</TT>
+ (a couple times, until no stars appear, in order configure)
+ </LI>
+ <LI> hit <TT>g</TT> (generate makefiles)
+ </LI>
+ <LI> hit <TT>q</TT> (quit ccmake)
+ </LI>
+ </UL>
+ </LI>
+ <LI> <TT>make</TT>
+ </LI>
+ <LI> <TT>make install</TT>
+ </LI>
+ <LI>[Optional] <TT>make test</TT>
+ </LI>
+</UL>
+
<!###################################>
<H2> Step by step recompilation</H2>
<UL>
-<LI> Retrieve gdcm the
- <A HREF="http://www.creatis.insa-lyon.fr/Public/Gdcm/cvs.html">
- sources through cvs</A>.
- We shall refer to this source directory as <TT>gdcmSources</TT>.
+<LI> Retrieve the
+ <A HREF="Cvs.html">
+ sources of gdcm through cvs</A>
+ and expand them in a source directory that we
+ shall refer as <TT>gdcmSOURCES</TT>.
</LI>
<LI> Create a compile directory (e.g. <TT>gdcmBin</TT>) that
we shall refer as <TT>gdcmBINARY</TT>.
- Change working directory to <TT>gdcmBINARY</TT>.
</LI>
-<LI> Invoke ccmake (from <TT>gdcmBINARY</TT>) with <TT>gdcmSources</TT>
- as source directory.
+<LI> [Optional] if you wish to install in a temporary installation
+ directory, create it. We shall refer to this directory
+ as <TT>gdcmINSTALL</TT>.
+</LI>
+<LI> Change working directory to <TT>gdcmBINARY</TT>.
+</LI>
+<LI> Invoke ccmake (from <TT>gdcmBINARY</TT>) with <TT>gdcmSOURCES</TT>
+ as source directory e.g. <TT>ccmake ../gdcm</TT> on Un*ces or
+ invoke <TT>CMakeSetup</TT> on Win32 and setup the source directory
+ and the compile directory.
<BR>
- Hit "c" for a first automatic configuration of your platteform
+ Hit <B><TT>c</TT></B> for a first automatic configuration
+ of your platteform.
</LI>
-<LI> Select the options that suite your needs. Basically this means
+<LI> Select the options that best suits your needs. Basically this means
toggling ON or OFF the following parameters
<UL>
- <LI> <TT>GDCM_DOXYGEN</TT>
- if you wish to generate the doxygen documentation,
- </LI>
<LI> <TT>GGDCM_VTK</TT>
- if you wish to generate the <A HREF="VtkGdcm.html">VTK wrappers</A>,
+ if you wish to generate the <A HREF="VtkGdcm.html">VTK wrappers</A>.
+ When automatic configuration fails you should manually set up
+ the cmake variable <TT>VTK_DIR</TT>.
</LI>
<LI> <TT>GDCM_WRAP_PYTHON</TT>
if you wish to generate the
<A HREF="html.developper/DoxyPythonComplete.html">Python wrappers</A>.
</LI>
+ <LI> <TT>GDCM_DOXYGEN</TT>
+ if you wish to generate the doxygen documentation,
+ </LI>
</UL>
</LI>
<LI> Among the other options, you might consider
toggling ON or OFF the following parameters
<UL>
+ <LI> <TT>CMAKE_INSTALL_PREFIX</TT>
+ should be set to <TT>gdcmINSTALL</TT>.
+ </LI>
<LI> <TT>BUILD_EXAMPLES</TT>
if you wish to generate the C++ gdcm examples,
</LI>
<LI> <TT>BUILD_TESTING</TT>
if you wish to generate gdcm test suite. When doing so you will
- need to retrieve gdcmData i.e. the set of Dicom image used in
- the test suite.
+ need to
+ <UL>
+ <LI> <A HREF="GdcmDataCvs.html">retrieve gdcmData</A>
+ i.e. the set of Dicom image used in the test suite and
+ expand them in a directory refered as <TT>gdcmDATA</TT>.
+ </LI>
+ <LI> setup cmake <TT>GDCM_DATA_ROOT</TT> to <TT>gdcmDATA</TT>.
+ </LI>
+ </UL>
+ </LI>
+ <LI> <TT>CMAKE_BUILD_TYPE</TT> can be set up to <TT>Debug</TT>
+ if you plan to use your native debugger.
+ </LI>
+ <LI> <TT>CMAKE_CXX_FLAGS</TT> for cautious developpers should be
+ set to
+ <TT>-g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter
+ -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated
+ -Woverloaded-virtual
+ </TT>
+ </LI>
+ </UL>
+</LI>
+<LI>
+ Hit <B><TT>c</TT></B> a couple times until they are no remaining "*"
+ (star character) preceeding the values of the gdcm variables.
+ <BR>
+ If you get warnings about
+ <TT>CMake forcing CMAKE_CXX_FLAGS</TT> (or other compiler variables)
+ simply ignore them and hit <B><TT>e</TT></B> to resume configuration.
+</LI>
+<LI>
+ Hit <B><TT>g</TT></B> in order to generate the makefiles (on Un*x)
+ or the workspace and project (on Win32).
+</LI>
+<LI>
+ Hit <B><TT>q</TT></B> to exit from <TT>ccmake</TT>.
+</LI>
+<LI> On Un*x launch <TT>make</TT>. On Win32 enter the VC++ gdcm.dsw
+ and lauch a <TT>build all</TT>.
+</LI>
+</UL>
+
+<!###################################>
+<H2>Installation</H2>
+This is an optional stage for developpers.
+<BR>
+On Un*x proceed with the install stage with <TT>make install</TT>.
+
+<!###################################>
+<H2>Running the test suite</H2>
+The impatient can run the full test suite with <TT>make test</TT>.
+<BR>
+For the test suite to be effective, you must have set
+<TT>BUILD_TESTING</TT> to <TT>ON</TT> when configuring <TT>ccmake</TT>.
+<UL>
+<LI>
+ <UL>
+ <LI> if you run the tests BEFORE installing then
+ positionate the environment variable <TT>GDCM_DICT_PATH</TT>
+ to <TT>gdcmSOURCES/Dicts</TT>
+ (e.g. <TT>export GDCM_DICT_PATH=$(gdcmSOURCES)/Dicts</TT>)
+ </LI>
+ <LI> if you run the tests AFTER installing then
+ positionate the environment variable <TT>GDCM_DICT_PATH</TT>
+ to <TT>gdcmINSTALL/share</TT>
+ (e.g. <TT>export GDCM_DICT_PATH=$(gdcmINSTALL)/Dicts</TT>)
+ </LI>
+ </UL>
+</LI>
+<LI>Assuming your current working directory is <TT>gdcmBINARY</TT>
+ the gdcm tests can be run in three different modes:
+ <OL>
+ <LI> Interactive access by number: run
+ <TT>./bin/gdcmTests</TT>
+ and select the number of the test you wish to run.
+ </LI>
+ <LI> Access to a test through it's name : pass the name of the
+ test as an argument to
+ <TT>./bin/gdcmTests</TT>
+ e.g.
+ <TT>./Test/gdcmTests TestAllEntryVerify</TT>.
+ </LI>
+ <LI> Launch the full test suite : (again we assume the
+ current working directory is <TT>gdcmBINARY</TT>)
+ run <B><TT>ctest</TT></B>. This is equivalent to <TT>make test</TT>.
+ <BR>
+ ctest supports some options (refer to the
+ <A HREF="http://www.cmake.org">CMake documentation</A>
+ for other options) :
+ <UL>
+ <LI> a verbose mode e.g. <TT>ctest -V</TT>
+ </LI>
+ <LI> argument filtering with regexp e.g. <TT>ctest -R print -V</TT>
+ runs the tests containing "print" in their name and
+ makes a verbose output.
+ </LI>
+ </UL>
</LI>
+ </OL>
</LI>
</UL>
Gdcm is yet another C++ library dedicated to reading/parsing and writing
<A HREF="http://medical.nema.org/">Dicom</A> medical files.
<BR>
-<B>GDCM</B>stands as a short for "<B>G</B>rass roots
+<B>GDCM</B> stands as a short for "<B>G</B>rass roots
<B>D</B>i<B>C</B>o<B>M</B>.
<!###################################>
</LI>
<LI>gdcm targets both GNU/Un*ces and Windows/VC++
(refer to
- <A HREF="html.developper/DoxyInstallation.html#DoxyRequirements">
- requirements</A>
+ <A HREF="Installation.html#gdcmRequirements">requirements</A>
for details).
</LI>
<LI>gdcm comes with a
<A HREF="http://public.kitware.com/VTK">VTK</A>
shallow wrapper class vtkGdcmReader (refer to
- <A HREF="">VtkGdcm.html</A>)
+ <A HREF="VtkGdcm.html">VtkGdcm</A>)
to ease the burden of VTK users,
<LI>gdcm also comes with
<A HREF="html.developper/DoxyPythonComplete.html">gdcmPython</A>
</TD></TR>
<TR><TD BGCOLOR="#99ccff">
- <A HREF="documentation.html"
+ <A HREF="html.developper/index.html"
target="rite">
- Documentation</A>
+ Full Documentation</A>
</TD></TR>
<TR><TD BGCOLOR="#99ccff">
- <A HREF="html.developper/DoxyDevelInstal.html"
+ <A HREF="Developpers.html"
target="rite">
Developpers</A>
</TD></TR>
+ <TR><TD BGCOLOR="#99ccff">
+ <A HREF="DeveloppersPython.html"
+ target="rite">
+ Python Developpers</A>
+ </TD></TR>
+
<TR><TD BGCOLOR="#99ccff">
<A HREF="Cvs.html"
target="rite">
<TR><TD BGCOLOR="#99ccff">
<A HREF="http://www.creatis.insa-lyon.fr/public/source/gdcm/"
target="rite">
- Browsing the sources</A>
+ Online browsing of sources</A>
</TD></TR>
git://git.creatis.insa-lyon.fr / gdcm.git / commitdiff