COMP: Fix missing itkdouble-conversion library when using packaged Slicer

Update ITKv4 version to include ITK commit f228cd4

// ----------
COMP: The install path for DoubleConversion lib was wrong.

As reported by Vladimir Chalupecky, the install path for
double-conversion libraries was wrong. I fixed and tested
that, and used the ITK Module-generated path variables
instead of ad hoc variables local to the DoubleConversion
Module.

See https://github.com/Kitware/ITK/commit/f228cd4
// ----------

Thanks to Marianna Jakab for reporting the issue.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21858 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Restore functioning of CLI loadable module by fixing ITKv4 regression

Problem is summarize by the discussion posted on the ITK developer list
reported below.

// --------------
Question from Jean-Christophe Fillion-Robin:

Following commit 4c47e7d [1] of February 19th and commit defb9c1 [2] of
March 1st, due to static initialization, the initialization of
ObjectFactory  now happens when ITK shared library are loaded [3][4].

This caused a regression in Slicer where the ObjectFactory were expected
to be loaded while attempting to load an image for the first time.

In Slicer case, the environment variable ITK_AUTOLOAD_PATH was set during
the initialization of the qSlicerCoreApplication, which is now too late.

By commenting line where a new ImageRegionSplitterSlowDimension is
instantiated [5][6] and updating the method "GetImageRegionSplitter /
GetGlobalDefaultSplitter" to return 0 [7][8], the initialization can
happen on demand instead of when ITK libraries are loaded.

An easy solution for us would be to ensure the "ITK_AUTOLOAD_PATH"
environment variable is set in the application launcher for Windows
and Linux application and set in Info.plist file associated with
the application bundle on MacOSX [9]

To provide more details, within Slicer we set the CMake variable
ITK_NO_IO_FACTORY_REGISTER_MANAGER before doing an
"include(${ITK_USE_FILE}) so that IOFactory are loaded only by
calling the method "itkFactoryRegistration" associated with a
shared library we named ITKFactoryRegistration. This approach allowed
us to disable the automatic registration of factory in selected part of
 the code. More details here [10]

It seems the new ITK commits 4c47e7d and defb9c1 prevent from completely
leveraging the use of ITK_NO_IO_FACTORY_REGISTER_MANAGER variable, the
code should probably be updated to consider this.

[1] https://github.com/Kitware/ITK/commit/4c47e7d
[2] https://github.com/Kitware/ITK/commit/defb9c1
[3] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
[4] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkObjectFactoryBase.cxx#L142-144
[5] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L760
[6] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
[7] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L765
[8] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L32
[9] http://www.herzbube.ch/blog/2009/01/how-set-environment-variables-mac-os-x-applications
[10] https://github.com/Slicer/Slicer/commit/03b8961
// --------------


// --------------
Answer from Brad Lowekamp:

This is quite an interesting side-effect of the changes I introduced.

I am glad that you were able to figure this out. For a variety of
reasons, it's likely a very bad thing for all that to occur during
static initialization in ITK. So it certainly needs to be fixed.

I agree that lazy initialization is the way to go. Unfortunately it
needs to be thread safe so its a little more completed.

ITKv4 performs the factory initialization when the user creates the
first ITK object.  And that changed with this patch, and need to be
fixed.

CONCLUSION:

Inside ITK, we can not use statically initialized ITK object.
// --------------

Issues:
 http://www.na-mic.org/Bug/view.php?id=3042
 http://www.na-mic.org/Bug/view.php?id=3008

ITK discussion:
 http://comments.gmane.org/gmane.comp.lib.itk.devel/1133

ITK patch:
 http://itk.org/gitweb?p=ITK.git;a=commit;h=1679816baef6b95356d9afdd9bd4a481ca08556c
 http://review.source.kitware.com/#/c/10645/

Fixes #3008
Fixes #3042

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21859 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Ensure extension Experimental targets are associated to Experimental track

Thanks for Ryan Eckbo developer of the "UKF extension" extension
for reporting and helping investigating the problem.

This regression is a side effect of commit r21682 [1] where parameters
are now written into files like:
  <extension-name>-test-command-args.cmake
  <extension-name>-upload-command-args.cmake
  <extension-name>-upload-only-command-args.cmake

And the file are then passed to the ctest using argument:

   -DSCRIPT_ARGS_FILE:FILEPATH=<path-to-args-file>

The written file are used to create custom targets:
  Experimenal .............. using EXTENSION_TEST_COMMAND
  ExperimentalUpload ....... using EXTENSION_UPLOAD_COMMAND
  ExperimentalUploadOnly ... using EXTENSION_UPLOAD_ONLY_COMMAND
  Nightly .................. using EXTENSION_TEST_COMMAND
  NightlyUpload ............ using EXTENSION_UPLOAD_COMMAND
  NightlyUploadOnly ........ using EXTENSION_UPLOAD_ONLY_COMMAND

Since the same files were used unconditionally for both Nightly and
Experimental targets, the latest value of CTEST_MODEL was used because
the latest set of files to be configured was done with CTEST_MODEL equal
to "Nightly".

This commit explicitly specify the value -DCTEST_MODEL:STRING=${CTEST_MODEL}
for each target command. Doing so ensure each command is associated with
the appropriate track.

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21860 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 3046. Fixed copy-paste error, use "transform" rather than "storage"

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21861 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: fix DWI loading in DICOM module by using DWIConvert module

Adapt to updates in DWIConvert by creating a target DWI volume
to store the output.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21862 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update build-system to use CMake'ified python

Latest stable version 2.7.3 is now used instead of ancient 2.6.6

Directory layout has been updated:
 - Python-2.7.3   : source
 - python         : build system
 - python-build   : build tree
 - python-install : install tree

Associated external project has been simplified. Removed unneeded
custom configure, make and install steps. Also removed unneeded
patch steps.

Note that the pythonrun.h and pythonrun.c are still patched in order
to prevent crash (related to dll boundaries [1][2]) when building Slicer debug
against a released python.

[1] http://stackoverflow.com/questions/2322095/why-does-this-program-crash-passing-of-stdstring-between-dlls
[2] http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/57e0d522-a42c-4add-963d-c87c6e76f161

Since only library located in the "lib-dynload" folder are not duplicated
in the "site-packages" folder, removed the exclude pattern
from the fixup script and update the candidate pattern to consider the
python extension located in lib/python2.7/lib-dynload folder.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21863 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Prevent python copy/compile possible issue when doing paralel build

Updated to CTK to integrate the following commits:

57d5e89 - Report a CMake error if script compilation fails
720397f - Regenerate python compile script at build tim
5800b08 - Compile python scripts explicitly instead of compiling an entire folder
68bf4c8 - Add option allowing to reduce number of python copy/compilation targets

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21864 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Do not include or use i18n macros if Slicer_BUILD_I18N_SUPPORT is OFF

Commit r21856 disabled internationalization support by default and
it introduced the option Slicer_BUILD_I18N_SUPPORT allowing to enable it.

This commit takes care of excluding the associated CMake macro and its
invocation if the option is disabled.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21865 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Remove custom version of FindSubversion.cmake not needed for CMake >= 2.8.3

In commit r16389, a custom version of the find module has been added
so that the associated macro can return the root url of the repository.

Starting with CMake 2.8.3 (commit 80bad29), the CMake built-in macro has
been updated to return the root.

Let's also note that the module provided with CMake >= 2.8.3 also include
a fix allowing the macro "Subversion_WC_INFO" to run as expected on non-US
system. ASsociated CMake issue is http://www.cmake.org/Bug/view.php?id=11273

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21866 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix MacOSX build errors following integration of CMake'ified python

The build errors introduced by commit r21863 and reported below
should now be fixed.

// -------------
Build errors:

[...]

dyld: Library not loaded: libpython2.7.dylib
  Referenced from: /Users/kitware/Dashboards/Nightly/Slicer-build-64bits-QT4.7.4-PythonQt-With-Tcl-CLI-Release-nightly/VTK-build/bin/vtkWrapPython
  Reason: image not found
[...]

Source: http://trunk.cdash.org/viewBuildError.php?buildid=82253
// -------------

Since the system where I did my test was having version 2.7.2 of python
installed in the system, the vtkWrapPython executable was resolving its
symbols against the system python and I didn't catch this error while
doing my test. On the other hand, the MacOSX factory coming with
version 2.6.1 of python, this particular problem occurred in that
specific case.

On Windows, the problem didn't happen because the DLL lives along
side the executable and on Linux the problem didn't happen because
the executable vtkWrapPython livres in the VTK build tree and was
embedding the location of the library using RPATH.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21867 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Remove unneeded FindCTK.cmake

When initially added in r15226, the FindCTK.cmake module allowed to
overcome an issue with "find_package" command preventing it from understanding the
REQUIRED parameter when dealing with Config file.

CMake 2.8.8 doesn't have this limitation anymore, CMake commit fa0f0654
fixes the issue.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21868 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Fix import of urllib MacOsx by updating CMake'ified python

Thanks to Steve Pieper for reporting the issue.

Following Slicer commit r21863 and commit r21867, CMake'ified python is
used to build Slicer. This commit update the python project so that the
python extension _scproxy is also built.

// ---------
The error being fixed was:

File "/Users/pieper/slicer4/latest/Slicer-superbuild/Slicer-build/lib/Slicer-4.2/qt-scripted-modules/SampleData.py", line 192, in downloadFile
  import urllib
File "/Users/pieper/slicer4/latest/Slicer-superbuild/python-install/lib/python2.7/urllib.py", line 1379, in <module>
  from _scproxy import _get_proxy_settings, _get_proxies
ImportError: No module named _scproxy
// ---------

The associated commit in CMake'ified python is:
https://github.com/davidsansome/python-cmake-buildsystem/commit/a813b59647eb40b8c6a3411eee83268ae98c9452

See http://na-mic.org/Bug/view.php?id=3052
Fixes #3052

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21869 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: fix paths for DICOM executable searches

Since the helper executables are not in the slicer bin directory
for a local build of slicer, be sure to also check in the DCMTK-build
bin directory to find the actual executable.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21870 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix sanity check associated with SlicerMacroConfigureGenericCxxModuleTests

The name of the variable and not its content was checked to be different
from an empty string.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21871 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix ExtensionsIndex experimental build error

Thanks to Chris Mullins for reporting the problem. Error is easily
reproducible when building an extensionsIndex with the option
-DSlicer_UPLOAD_EXTENSIONS:BOOL=ON. See below for detailed command
and associated error message.

Following commit r21860 ensuring target ExperimentalUpload, ExperimentalNightly,
... works as expected. The case when Slicer_UPLOAD_EXTENSIONS is ON and
the build is done manually instead of being driven by a dashboard hasn't been
tested :(

To fix the issue, we assume that by default a manual build of an
ExtensionsIndex corresponds to an Experimental build. The user can still
pass CTEST_MODEL at the command line if he wishes to change the value.

// -------------------
Error:

cmake -DSlicer_DIR:FILEPATH=/home/crmullin/Projects/Slicer4-SuperBuild-Debug/Slicer-build/ \
 -DSlicer_EXTENSION_DESCRIPTION_DIR:FILEPATH=/home/crmullin/ExtensionsIndexForTubetk/ \
 -DCMAKE_BUILD_TYPE:STRING=Release \
 -DSlicer_UPLOAD_EXTENSIONS:BOOL=ON \
 /home/crmullin/Slicer/Extensions/CMake/

[..]
Scanning dependencies of target JsonCpp
[  5%] Creating directories for 'JsonCpp'
[ 11%] Performing download step (git clone) for 'JsonCpp'
Cloning into 'JsonCpp'...
[...]
[ 16%] [ 22%] No patch step for 'JsonCpp'
Performing update step (git fetch) for 'JsonCpp'
HEAD is now at e2cfe02... Merge branch 'master' of github.com:TubeTK/jsoncpp-cmake
[ 27%] No configure step for 'JsonCpp'
[ 33%] No forcebuild step for 'JsonCpp'
[ 38%] Performing build step for 'JsonCpp'
* Extra verbosity turned on
Reading Script: /home/crmullin/Slicer/Extensions/CMake/SlicerBlockBuildPackageAndUploadExtension.cmake
SetCTestConfiguration:SourceDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp-build/Extensions-
SetCTestConfiguration:BuildDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp
Run dashboard with model TRACK
   Source directory: Extensions-
   Build directory: /home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp
CMake Error at /home/crmullin/Slicer/Extensions/CMake/SlicerBlockBuildPackageAndUploadExtension.cmake:90 (ctest_start):
  ctest_start given source path

    /home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp-build/Extensions-

  which is not an existing directory.  Set CTEST_CHECKOUT_COMMAND to a
  command line to create it.

SetCTestConfiguration:BuildDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp-build
SetCTestConfiguration:SourceDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp
SetCTestConfiguration:ConfigureCommand:"/home/crmullin/cmake-2.8.10.2/bin/cmake" "-DCMAKE_BUILD_TYPE:STRING=Release" "-GUnix Makefiles" "/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp"
SetCTestConfiguration:BuildDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp-build
SetCTestConfiguration:SourceDirectory:/home/crmullin/Projects/SlicerExtensionsIndex-tubetk/JsonCpp
Configure project
Current Tag empty, this may mean NightlyStartTime / CTEST_NIGHTLY_START_TIME was not set correctly. Or maybe you forgot to call ctest_start() before calling ctest_configure().
Cannot open configure file
Error in read script: /home/crmullin/Slicer/Extensions/CMake/SlicerBlockBuildPackageAndUploadExtension.cmake
make[2]: *** [JsonCpp-prefix/src/JsonCpp-stamp/JsonCpp-build] Error 255
make[1]: *** [CMakeFiles/JsonCpp.dir/all] Error 2
make: *** [all] Error 2

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21872 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix macro SlicerMacroConfigureGeneric{Cxx, Python}ModuleTests sanity checks

Commit r21871 fixed the sanity check associated with macro
"SlicerMacroConfigureGenericCxxModuleTests" by testing the content of
the variable.

This approach works well for function. In case of macro, only parameter
referenced using ${argX} are replaced. It means the following code
doesn't work:

// ----------
macro(foo bar)
  set(var "foo")
  message("${var}:${${var}}")
endmacro()

foo("hello")
// ----------

It outputs:

  foo:

whereas the following is expected:

  foo:hello

This commit fix the problem by explicitly testing the parameter value.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21873 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: #2932, #3001, #3002 Several improvements to the editor.

#2932 - new Pixel Mode in Paint tool allows precise control when zoomed
in close to the image.

Add a set of hotkeys per #3002 for editor-wide functions, also
new +/- control on the paint brush to adjust size while it is active.

Per #3002 if a master and merge volumes already have been selected,
don't reset them when entering the editor.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21874 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: for issue #3002 fix eyedropper

Make sure all label effects have an instance of their logic class
and that the allow the superclass to optionally process keystrokes
and other events (this allows the eyedropper operation to work).

See keystroke list here:
http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/Editor#Keystrokes

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21875 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: fix spurious warning message

If there had been no study added in the past month, a string format
operation would fail and generate a warning.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21876 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Enhancement to Tractography Display and ROI selection: Fiber selected by default, ROI interactive mode and visibility exposed, other minor UI improvements 

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