COMP: Revert "BUG: LibXml2 is required for building."

Commit r22008 explicitly disable the search of library not needed to
build LibArchive. Then, commit r22009 has been pushed to re-enable the
lookup of LibXml2.

The original intent of commit r22009 was to fix
a build error occurring when configuring LibArchive in an existing
build tree with option -DCMAKE_DISABLE_FIND_PACKAGE_LibXml2:BOOL=OFF.

Since it is required to delete the LibArchive build tree so that the
variable "HAVE_LIBXML_XMLREADER_H" is not set by a previous lookup
of LibXml2, this new commit is reverted.

Forcing the value "HAVE_LIBXML_XMLREADER_H" to a "notfound" value
will also ensure that re-build of existing tree won't cause problem.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22012 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: LibArchive-* dirs should be deleted to avoid build errors

Forcing "HAVE_LIBXML_XMLREADER_H" to a "notfound" value as it is
done in commit r22012 has no effect on an existing build tree.

This is confirmed by http://slicer.cdash.org/viewBuildError.php?buildid=98584

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22013 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: On MacOSX, do not create duplicate of MRMLIDIOPlugin and MGHIOPlugin

This fix MacOSX warning "/path/to/plugin is already loaded"

Both MRMLIDIOPlugin and MGHIOPlugin were copied so that it exists both
a "dylib" and a "so" version of the file. This was initially committed
on the 2007-09-27 to work around a limitation of ITK preventing it from
loading plugin having ".dylib" extension. See Slicer3 r4454 [1]

Then 2 months later, on the 2007-11-19, a fix has been pushed in ITK so
that plugin having extension "dylib" are considered. See ITK commit 28b4a6ba [2]

This commit account for the ITK fix by removing the code in charge of
copying the plugin.

Lessons learned: When implementing a hack, it is a good practice to report
a bug upstream to track the limitation and also reference the bug in a
comment starting with either "# HACK" for CMake file or "// HACK" for
c/cpp files. It would give a hint to developer re-factoring the code.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer3?view=revision&revision=4454
[2] https://github.com/Kitware/ITK/commit/28b4a6ba

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22014 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Move MacOSX configuration code for CLI factory to a better place.

As a slight improvement, the path is also appended only if it exists.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22015 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Simplify logic by appending path to CLI factory only if they exist.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22016 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Do not check for version of CMake before including "BundleUtilities"

Since minimum required CMake version for Slicer is 2.8.9, this message
is not needed anymore.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22017 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Ensure Python library directory is considered when fixing up package

When the expression "@SLICER_PYTHON_LIB_DIR@" has been introduced
in commit r21252 [1], it was already resolving to an empty
string because since r15463 [2] the file SlicerBlockCTKAppLauncherSettings is
included in the Applications/SlicerApp/CMakeLists.txt.

Both the fixup script and the launcher settings have been updated to
use the variable "PYTHON_LIBRARY_PATH" introduced in the top-level
CMakeLists.txt by commit r16822 [3]

To prevent such error from happening again, a convenient macro named
"_fixup_paths_append" has been introduced. It basically check if the path
passed as parameter exists and append it to the list of paths. If not,
it throw an error.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21252
[2] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=15463
[3] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=16822

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22018 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Ensure library paths used for BundleFixup are valid

The helper macro "_fixup_paths_append" is now used consistently to append
path to the "libs_path" variable.

Let's also note the following updates:

 - CMAKE_RUNTIME_OUTPUT_DIRECTORY is not used anymore, instead
${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@ is used.

 - Path "@Slicer_BINARY_DIR@/@Slicer_QtPlugins_DIR@" is not considered
anymore since it didn't exist in the build tree. Instead, the plugin path
are composed using "${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@"

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22019 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Do not explicitly fixup CLI shared libraries

Considering that (1) CLI shared lirbary are dependency
of CLI executable and (2) CLI executable are already discovered by the
fixup mechanism. There are no need to use candidate pattern for CLI
shared library.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22020 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Simplify expression used in gp_item_default_embedded_path_override.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22021 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Easier configuration of fixup path in bundle script

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22022 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Ensure library can be loaded from different place using @rpath

Before this commit, attempt have been made (r18311, r18325, r18581) to
install both built-in CLI and extension CLI executable in a folder
located at some depth of the main Slicer executable. This was needed
because all libraries were referenced based on the location of the main
Slicer executable using "@executable_path". This was working *only* in the
case of built-in CLI but wasn't scaling very well for the extension CLI
executable. Indeed, being able to both differentiate the different
installed extension and keeping the depth to 1 level wasn't easily
feasible:

  /path/to/Slicer.app/Contents/MacOS/Slicer
  /path/to/Slicer.app/Contents/cli-modules/MyCLI
  /path/to/Slicer.app/Contents/Extensions-21855/SkullStripper/cli-modules/MyCLI

A solution could have been to install extensions directly in "Slicer.app"
folder and update the cli install sub dir to get something like:

  /path/to/Slicer.app/Extensions-21855/SkullStripper/MyCLI

While possible, it would have remain a special case to maintain.

Instead, by using "@rpath", CLI modules can now be installed in the Slicer
standard location "Slicer_CLIMODULES_LIB_DIR" instead of "Slicer_CLIMODULES_SUBDIR".
This commit remove the special case which never worked (issue #3051)

Waiting the topic "tweak-bundleutilities-for-rpath" is fully matured and
integrated in CMake, use custom version of BundleUtilities and GetPrerequisites.
See http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bundleutilities-for-rpath

Since our custom version of the CMake modules now consider "~/usr/.*/lib",
the implementation of "gp_resolved_file_type_override" has been removed.

Remove the hack specific to LibArchive (introduced by commit r19615), since
the library is fixed up using the default library matching pattern, it
will be installed in the expected location.

SlicerExecutionModel has also been updated to link the CLI executable
and library with "-rpath" so that they can resolve the location of Slicer
libraries.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22023 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Remove check of spacing in LabelStatistics

Because small differences in spacing can be introduced by rounding
or the way floating point numbers are handled, the check of exact
equality caused false negatives.  Removing this check will allow
valid use cases to succeed, while the other checks still prevent
incorrect calculations (where the grids to not actually align in
pixel space).

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22024 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Ensure out-of-source CLI module use Slicer library wrapper

Commit r19677 removed the setting of Slicer_CLI_SHARED_LIBRARY_WRAPPER_CXX
from SlicerConfig by ensuring the use of the wrapper provided
by SlicerExecutionModel.

Then, commit r21592 added the ITKFactoryRegistration library and
also re-introduced a custom cli wrapper without making sure module
externally built would consider it.

This commit set "SlicerExecutionModel_CLI_LIBRARY_WRAPPER_CXX" in
SlicerConfig.cmake to allow module externally built to consider
the Slicer wrapper. It also address the issue discussed in the
following Slicer thread: http://massmail.spl.harvard.edu/public-archives/slicer-devel/2013/012491.html

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22025 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Simplify external project removing CMake 2.8.8 compatibility

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22026 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Reference private member using "this->"

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22027 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Fixes duplicate class name so that correct constructor is called

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22028 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Use qRestAPI instead of deprecated qMidasAPI project

In addition to provide Midas support, qRestAPI also provides
support for XNat (qXnatAPI.h)

See https://github.com/commontk/qRestAPI

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22029 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix inconsistent linkage error related to qRestAPI

Associated qRestAPI commit is commontk/qRestAPI@6339e0c and
the corresponding message as been copied below:

// -------------
Support windows static build

Following commit commontk/qRestAPI@5c056f2, the project could be built as a shared library
this caused problem on windows where the qRestAPI_EXPORT macro was
also defined in the case of static build causing an "inconsistent linkage"
error.

This commit explicitly define qRestAPI_EXPORT based on the
BUILD_SHARED_LIBS option.
// -------------

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22030 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix linux build of qRestAPI

Ironically, while commit r22030 fixed windows static build it also
broke linux build. This commit fixes the problem.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22031 3bd1e089-480b-0410-8dfb-8563597acbee