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
COMP: Fix clang build error related to qRestAPI

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

// -------------
Fix build CLang build error by making static helper method
 public.

For the record, the reason this fails on Mac and not on Linux is
the following :
http://clang-developers.42468.n3.nabble.com/Access-to-static-protected-member-from-friends-of-derived-classes-td4030444.html

The Q_DECLARE_PRIVATE macro declares the qXnatAPIPrivate class and makes
it a friend of qXnatAPI, which is sufficient for G++ to give it access to
qRestAPI's static protected methods, but the Clang developers have a
different understanding of the standard, so it doesn't work on Clang.

Thanks to Steve Pieper, Florian Vichot and Sascha Zelzer for their
help fixing the issue.
// -------------

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22032 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix unused variable warnings related to qRestAPI project

See commontk/qRestAPI@5a81c92f9

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22033 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix configure error occurring when using XCode generator

Note that this fix only allow an "Archive" build to be successfully
done using Xcode. This could be done through the menu "Product" ->
"Build For" -> "Archiving"

Commit r21879 ensured python was systematically build in Release
on multi-configuration generator.

Since additional external project steps specific on unix and apple
system were not considered by the previous fix, it was causing
configure error like the one reported below:

  ../ExternalProject.cmake:1049 (add_custom_command):
  add_custom_command given APPEND option with output
  "/Volumes/Dashboards/Experimental/Slicer-Superbuild-Release-cmake-2.8.11-XCode/CMakeFiles/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/python-complete"
  which is not already a custom command output.
  [...]

This commit ensure that the additional steps consider the value of
"CMAKE_CFG_INTDIR" forced to Release.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22034 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Added selection, de-selection, deleting-of-selected fibers.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22035 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix Xcode build error related to vtkpng library

This commit ensure that "CMAKE_CFG_INTDIR" is considered on all
multi-configuration environment and not only windows.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22036 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: ExtractSkeleton - Fix clang -Wparentheses-equality warning

Detailed output from Clang:

 warning: equality comparison with extraneous parentheses [-Wparentheses-equality]
        if( (result[i] == OBJ) )
             ~~~~~~~~~~^~~~~~
 note: remove extraneous parentheses around the comparison to silence this warning

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22037 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Allow use of 'project()' in CMakeLists.txt of extension/module

The previous approach enforcing to NOT use "project()" in CMakeLists.txt
is not required anymore.
This was done so that SlicerConfig.cmake included after calling
"find_package(Slicer)" could:
  (1) include SlicerBlockSetCMakeOSXVariables
  (2) then call the project() statement

Using recent version of CMake, this "hack" was preventing extension from
being built.

To prevent the configure error, "SlicerBlockSetCMakeOSXVariables" is not
included anymore automatically after calling "find_package(Slicer)"

That said, to allow the CMAKE_OSX_* to (optionally) be set automatically,
a different approach is now considered.

This also make it possible to call "project()" within the CMakeLists.txt
of extension or module.

To optionally have the CMAKE_OSX_* variable set within a project, the
developer could call:

 find_package(Slicer COMPONENTS ConfigurePrerequisites)

before any "project()" calls.






For completeness, the discussion with CMake developer regarding the possible
approach to automatically set the CMAKE_OSX_* variables have been
reported below.

// ------------------
From Jc:

Hi Brad,

To summarize, the user build a building using a line similar to:

  cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

  Passing Slicer_DIR is the only requirement.

// ------------------
You are right the file in source/build tree won't help.

// ------------------
Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake and I would like the plugin to use these. The current approach is to force the following convention:

    set(EXTENSION_NAME "Foo")

    find_package(Slicer)
    include(${Slicer_USE_FILE})

    [...]

where project() was called within the Slicer use file.

// ------------------
By using this new approach:

   find_package(Slicer COMPONENTS ConfigurationPrerequisites)

   project(Foo)

   find_package(A ..)
   find_package(B ..)

  Can I be sure that the first call to "find_package" will be done before language feature are enabled ?

Thanks
Jc


// --------------------------
From Brad:

On 04/19/2013 10:54 AM, Jean-Christophe Fillion-Robin wrote:
>   cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

Great, so find_package doesn't actually need to search but only
load the package config file.

> Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake
> and I would like the plugin to use these. The current approach is
> to force the following convention:
>
>     set(EXTENSION_NAME "Foo")
>     find_package(Slicer)
>     include(${Slicer_USE_FILE})
>
> where project() was called within the Slicer use file.

Instead of the above three lines, try these three::

 project(Foo NONE)
 find_package(Slicer)
 SlicerConfigPlugin()

SlicerConfig.cmake provides the SlicerConfigPlugin macro to:

* FATAL_ERROR if languages are already enabled and tell the
  plugin author to add NONE to the project command

* Get the extension name from PROJECT_NAME, or alternatively
  from an optional explicit argument

* Set OS X platform variables and call enable_language()

Larger projects that provide a Slicer plugin along with a bunch
of other unrelated stuff will not want Slicer to control their
enable_language calls.  Therefore SlicerConfig should add another
macro (or options to this one) to just check that an already
enabled language has a matching platform selection and skip its
enable_language calls.

>    find_package(Slicer COMPONENTS ConfigurationPrerequisites)
>    project(Foo)
>    find_package(A ..)
>    find_package(B ..)
>
>   Can I be sure that the first call to "find_package" will be
>   done before language feature are enabled ?

Yes, but the above method may be even simpler.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22038 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Added help text for the edit fibers checkbox

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22039 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 3054. Added dimensions check in ImageLabelCombine module

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22040 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Reduce number of copy/compile python targets

Set variable CTK_COMPILE_PYTHON_SCRIPTS_GLOBAL_TARGET_NAME
to "Slicer" to create targets:
  CopySlicerPythonResourceFiles
  CopySlicerPythonScriptFiles
  CompileSlicerPythonFiles

Before this commit, for each set of script processed directly or
indirectly by the macro "ctkMacroCompilePythonScript", two targets
are created. For example:

[...]
CopyAAAPythonFiles
CopyAAAPythonResourceFiles
CompileAAAPythonFiles
[...]
CopyBBBPythonFiles
CopyBBBPythonResourceFiles
CompileBBBPythonFiles
[...]
CopyCCCPythonFiles
CompileCCCPythonFiles
[...]

After integrating the commit, independently of the number
of set of scripts, within Slicer core the following three
targets will be available:

  CopySlicerPythonResourceFiles     [If there are python resources]
  CopySlicerPythonScriptFiles
  CompileSlicerPythonFiles

Note that this will apply only for Slicer core, by default,
if an extension bundles 2 scripted modules, the following targets
will be available:

  CopyModule1PythonScriptFiles
  CompileModule1PythonFiles

  CopyModule2PythonResourceFiles
  CopyModule2PythonScriptFiles
  CompileModule2PythonFiles

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22041 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: moved label to tool tip

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22042 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Fix ExtensionsManager model tests on MacOSX and Windows

By default [1], on macosx and windows, settings format is not Ini.
This commit ensure this is the case.

[1] http://qt-project.org/doc/qt-4.8/qsettings.html#Format-enum

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