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
BUG: Fix extractExtensionArchive test on MacOSX

Similarly to what has been done on Windows platform in
r20083 [1] this commit also excludes the readonly destination
path test on MacOSX.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=20083

See also issue #2053

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22044 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix superbuild extension template build error

Following r21776[1], the description hasn't been renamed whereas
the associated directory was. This was preventing the
testing extensions from being built successfully. See error reported
below.

This commit rename the description file.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21776


// -------------
[...]
-- Configuring extension: SuperBuildLoadableExtensionTemplate
.CMake Error at C:/D/Support/CMake 2.8.10.2/share/cmake-2.8/Modules/ExternalProject.cmake:1334 (message):
  error: no download info for 'SuperBuildLoadableExtensionTemplate' -- please
  specify existing/non-empty SOURCE_DIR or one of URL, CVS_REPOSITORY and
  CVS_MODULE, SVN_REPOSITORY, GIT_REPOSITORY, HG_REPOSITORY or
  DOWNLOAD_COMMAND
Call Stack (most recent call first):
  C:/D/Support/CMake 2.8.10.2/share/cmake-2.8/Modules/ExternalProject.cmake:1699 (_ep_add_download_command)
  SlicerBlockBuildPackageAndUploadExtensions.cmake:156 (ExternalProject_Add)
  CMakeLists.txt:85 (include)


-- Configuring incomplete, errors occurred!
[...]
//---------------

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22045 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update CTK / PythonQt - Fix msvc 2010/2012 build error

See commontk/CTK@2c24951c9

Thanks to @ihnorton for testing the patch.

See #2002

Complete list of associated CTK changes: https://github.com/commontk/CTK/compare/bedf1712d4...1c0977af174

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22046 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix msvc 2012 build error in vtkMRMLAbstractDisplayableManager

From: Isaiah Norton <isaiah.norton@gmail.com>

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22047 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update CTestCustom to exclude "HEAD is now" git warning.

Despite the fact the git client on the different Slicer dashboard
client has been setup with "advice.detachedHead" warning disabled [1]

The "HEAD is now ..." output still show up as a warning on CDash.
See http://slicer.cdash.org/viewBuildError.php?type=1&buildid=103147

This commit attempts to suppress it.

[1] http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Tutorials/DashboardSetup#Setup

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