COMP: NUMPY Requires a the use of fortran

Propogating compiler flags and compiler options for the
fortran compilers needed for NUMPY.

http://projects.scipy.org/numpy/ticket/182

NINJA compiler is excluded as it explicitly does not support fortran.

See http://na-mic.org/Mantis/view.php?id=2276

Fixes #2276

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20520 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: GPU memory setting failed from being restored

This is because ctkSettingsPanel couldn't support 2 properties registered
from the same sender

Issue #2270

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20521 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Update qMRML*TranslatorPlayerTests to account for updated spinbox translator/player

See http://paraview.org/gitweb?p=QtTesting.git;a=commit;h=24d549c48f6ec5c7a86a44e862a8c62ab0311d03

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20522 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Remove unused CMake code, fix indent, use message(STATUS ...

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20523 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Building Numpy with Fortran is optional

If no Fortran compiler is found, it will result in a less optimized
Numpy build.
See http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:enable_language

See #2276 / http://na-mic.org/Mantis/view.php?id=2276

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20524 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: At configuration - Numpy Fortran compiler details are nicely displayed

Macro SlicerMacroCheckExternalProjectDependency has also been updated
to set the variables:
  __${proj}_indent
  __${proj}_superbuild_message

These variables can be used to print additional information associated with
an external project.

See #2276 / http://na-mic.org/Mantis/view.php?id=2276

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20525 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Avoid GET_FILENAME_COMPONENT error in CMakeFortranInformation.cmake

See http://www.cmake.org/Bug/view.php?id=9220#c18600

See #2276 / http://na-mic.org/Mantis/view.php?id=2276

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20526 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Simplify extension build system removing EXTENSION_HAS_ONLY_ONE_MODULE mode

Extension metadata are expected to be set using "EXTENSION_*" variables.

In case only the variable MODULE_NAME is defined, the metadata will also be
expected to be defined using EXTENSION_* variables.

This change is not backward compatible.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20527 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Prevent confusion - Do not set partially supported metadata in extension template

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20528 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Remove ModuleTemplate and use LoadableExtensionTemplate instead

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20529 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Simplify header includes in "Annotation MRMLDisplayableManager"

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20530 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Add Documentation folder to loadable extension templates

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20531 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: For sake of consistency, specify module files using MODULE_NAME variables

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20532 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Add Widget library to LoadableExtensionTemplate

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20533 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Do not use Fortran compiler on windows

On windows, "enable_language(Fortran OPTIONAL)" failed with error and
is not usable.

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

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

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

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20536 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Added ctk material properties widget to TractographyDisplayWidget

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20537 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: Interface improvement in the tractography display module: consistent selection of the nodes

git-svn-id: http://svn.slicer.org/Slicer4/trunk@20538 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Prevent NUMPY runtime issue by using its built-in "clapack"

Summary:

* CLAPACK is not needed anymore.

* Also refactored and simplified the different NUMPY steps. There are now
three distinct steps: configure, make and install

Details:

* All the steps include a common file named "NUMPY_environement.cmake" that
both set the environment within each step and provide a convenient
macro "numpy_setup_command" allowing to invoke "setup.by".

* After investigating, it resumes it is pointless to compile CLAPACK and
build numpy against it. Indeed, the modules "blas_lite.c" and
"dlapack_lite.c" already bundle part of CLAPACK that are required
by "linalg" numpy module.

While looking for the root cause of the problem, I also realized
that CLAPACK can't be linked against numpy. The "f2c.h" bundled
within clapack-3.2.1-CMAKE.tgz is different from the "f2c.h"
available in "numpy/linalg" folder. For example, the typedefs used
to specify "integer" or "uinteger" are different.

In clapack/INCLUDE/f2c.h => "integer" is defined as "long int"
In numpy/linalg/f2c.h => "integer" is defined as "int"

Within the python module "lapack_litemodule.c", we can read that
the function signature used to specify the function to link against
is of the form:

 extern int foo_(char *arg1, char *arg2, int *n)

whereas in CLapack, the same function is defined as:

 int foo_(char *arg1, char *arg2, integer *n)    // integer being "long int"

This difference in type was causing the error reported in the bug.

While working on that issue, I also created a small project
illustrating the problem. See https://github.com/jcfr/CFunclash#readme

On linux 64bit (Ubuntu 10.04), the following numpy test suite run without
any errors:

=> nose version 1.1.2
=> gcc 4.4.3

>>> numpy.test()
[...]
Ran 2483 tests in 10.194s

OK (KNOWNFAIL=4, SKIP=12)


Details (package by package)

>>> np.linalg.test()
Running unit tests for numpy.linalg
NumPy version 1.4.1
[...]
Ran 116 tests in 0.203s

OK
<nose.result.TextTestResult run=116 errors=0 failures=0>


>>> np.ma.test()
Running unit tests for numpy.ma
NumPy version 1.4.1
[...]
Ran 282 tests in 1.011s

OK
<nose.result.TextTestResult run=282 errors=0 failures=0>


>>> np.polynomial.test()
Running unit tests for numpy.polynomial
NumPy version 1.4.1
[...]
Ran 86 tests in 0.324s

OK
<nose.result.TextTestResult run=86 errors=0 failures=0>


>>> np.random.test()
Running unit tests for numpy.random
NumPy version 1.4.1
[...]
Ran 11 tests in 0.020s

OK
<nose.result.TextTestResult run=11 errors=0 failures=0>


>>> np.fft.test()
Running unit tests for numpy.fft
NumPy version 1.4.1
[...]
Ran 5 tests in 0.023s

OK
<nose.result.TextTestResult run=5 errors=0 failures=0>


>>> np.core.test()
Running unit tests for numpy.core
NumPy version 1.4.1
[...]
Ran 861 tests in 2.181s

OK (KNOWNFAIL=4, SKIP=11)
<nose.result.TextTestResult run=861 errors=0 failures=0>


>>> np.linalg.test()
Running unit tests for numpy.linalg
NumPy version 1.4.1
[...]
Ran 116 tests in 0.184s

OK
<nose.result.TextTestResult run=116 errors=0 failures=0>

>>> np.matrixlib.test()
Running unit tests for numpy.matrixlib
NumPy version 1.4.1
[...]
Ran 38 tests in 0.077s

OK
<nose.result.TextTestResult run=38 errors=0 failures=0>


>>> np.lib.test()
Running unit tests for numpy.lib
NumPy version 1.4.1
[...]
Ran 994 tests in 6.313s

OK (SKIP=1)

>>> numpy.oldnumeric.test()
[...]
Ran 2 tests in 0.020s

OK


>>> numpy.testing.test()
[...]
Ran 69 tests in 0.128s

OK

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