Windows support

[KrisThielemans]

At present, most configurations will fail for Windows.
Probably our best strategy is to download precompiled packages and use those.

[KrisThielemans]

With CMake 3.9-rc4 I successfully built with pre-downloaded Boost, HDF5 and FFTW (as per the wiki) and at commit 0eabb88

(command lines were in Powershell)

cd C:\Users\krisf\Documents\devel\SIRF-SuperBuild-CMake3.9-64
~/Documents/devel\CMake-Build\INSTALL\bin/cmake  -DBOOST_ROOT=C:/Users/krisf/Documents/devel/boost_1_63_0   -DUSE_SYSTEM_Boost=On -DUSE_SYSTEM_HDF5=On -DCMAKE_GENERATOR_PLATFORM=x64   -DCMAKE_INSTALL_PREFIX=C:\Users\krisf\Documents\devel\SIRF-SuperBuild-CMake3.9-64/INSTALL -DUSE_SYSTEM_FFTW3=On -DFFTW3_ROOT_DIR=C:/Users/krisf/Documents/devel/fftw-3.3.5-dll64 C:/Users/krisf/Documents/devel/SIRF-SuperBuild

[KrisThielemans]

Some difficulties encountered with HDF5:

• Anaconda comes with a very old HDF5 which has a bug in its hdf5-config.cmake (pointing to a non-existent c:\aroot folder for zlib etc)
• HDF5 1.10.0-patch1 has a bug that it cannot be installed with RelWithDebInfo (it has incorrect info for installing .ptb files). This is resolved in 1.10.1.
• it seems impossible to force CMake to find a specific version by setting HDF5_DIR. This might be due to a bug in FindHDF5.cmake (it only goes for the config version if HDF5_ROOT is set) but even when I try to fix that, it still doesn't find it.
• If CMake doesn't find the config, there are 2 problems when HDF5 is built with shared libraries (which is the default):
  • FindHDF5 (even in 3.9) doesn't add setting the preprocessor variable H5_BUILT_AS_DYNAMIC_LIB to HDF5_DEFINITIONS when in Module-mode. We could fix that (see https://gitlab.kitware.com/cmake/cmake/merge_requests/1023)
  • Even if we'd set HDF5_DEFINITIONS, ISMRMRD/CMakeLists.txt (and Gadgetron) does not use it yet (see use HDF5_DEFINITIONS ismrmrd/ismrmrd#92)

Summary:

• when installing recent HDF5 libraries (in Program Files), it works with CMake 3.9, as long as we let CMake ignore our HDF5 version. Without the Program Files version, CMake finds the Anaconda-HDF5 and it breaks.
• it might be possible to ignore most of these bugs if we'd build with HDF5 static libraries

[KrisThielemans]

Just checked that adding -DHDF5_USE_STATIC_LIBRARIES=1 still needs a change to FindHDF5 as the relevant lines there are only enabled on Unix. Fix is in
https://gitlab.kitware.com/cmake/cmake/merge_requests/1023

So, sadly it seems that unless we can force CMake to find our Config-install of HDF5 (see https://gitlab.kitware.com/cmake/cmake/issues/17029), we can only build with an installed HDF5 in Program Files (at least until FindHDF5.cmake gets fixes)

[KrisThielemans]

Started testing with CMake 3.10.1 (which has the relevant fixes for FindHDF5.cmake).

Current problems:

1. had to fix detection of x64
2. CMAKE_INSTALL_PREFIX was not reset from the default (should normally have been set ok)
3. USE_SYSTEM_HDF5 was not correctly honoured (When I ran CMake, it said it was using the system version, but Visual Studio went ahead and downloaded source and compiled anyway).
4. ISMRMRD failed to link against own compiled HDF5 because that was compiled for 32-bit. message:

library machine type 'X86' conflicts with target machine type 'x64'

5. When building in Debug-mode, Python link fails, see Debug-build on Windows fails unless python27_d.lib is present SIRF#42

Items 2 and 3 might have been because I ran CMake a few times (with deleting the cache and without) before settling on USE_SYSTEM_HDF5=On. It's strange/undesirable though. Will need to check again later.

[KrisThielemans]

confirmed that when deleting the cache, configuring, and then clicking USE_SYSTEM_HDF5 does work as expected (also for CMAKE_INSTALL_PREFIX). Not sure how to reproduce the above problems 2 and 3 so I am going to ignore them...

[KrisThielemans]

CTest fails because config option isn't passed on:

ctest -VV -C Release
...
test 1
    Start 1: SIRF_TESTS

1: Test command: "C:\Program Files\CMake\bin\ctest.exe" "test"
...
1:     Start 1: PET_TEST1
1: Test not available without configuration.  (Missing "-C <config>"?)
1: 1/3 Test #1: PET_TEST1 ........................***Not Run   0.00 sec
...
Can we add this option on other systems?

[KrisThielemans]

Going to the relevant subdir, PET tests work after setting PYTHONPATH! In Powershell

cd SIRF-prefix\src\SIRF-build\src\xSTIR
Env:PYTHONPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python"
ctest -VV -C Release
...
100% tests passed, 0 tests failed out of 1

MR tests fail with error

1: Traceback (most recent call last):
1:   File "fully_sampled.py", line 22, in <module>
1:     from pGadgetron import *
1:   File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pGadgetron.py", line 41, in
<module>
1:     import pygadgetron
1:   File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pygadgetron.py", line 17, in
 <module>
1:     _pygadgetron = swig_import_helper()
1:   File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pygadgetron.py", line 16, in
 swig_import_helper
1:     return importlib.import_module('_pygadgetron')
1:   File "C:\Users\krisf\Anaconda2\lib\importlib\__init__.py", line 37, in import_module
1:     __import__(name)
1: ImportError: DLL load failed: The specified module could not be found.

This means that a DLL isn't in the Path. Sadly, Windows doesn't say which one. Obvious candidate is the ISMRMRD DLL but the following didn't help

$env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\bin"

@evgueni-ovtchinnikov , do you know how to set the PATH correctly?

[KrisThielemans]

Compilation problems should be fixed with #64.

Still need to fix above ctest and DLL problems, and also create .bat and .PS1 files with appropriate settings. @evgueni-ovtchinnikov and @paskino can you find the correct settings and then creating the configure file?

[KrisThielemans]

Currently tested with USE_SYSTEM_BOOST=ON only, but USE_SYSTEM_FFTW ON/OFF, USE_SYSTEM_HDF5 `ON/OFF'.

old version of HDF5 (1.8.15) with out-of-date conda gives

LINK : fatal error LNK1181: cannot open input file 'C:\aroot\stage\Library\lib\z.lib' [C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\ISMRMRD-prefix\src\ISMRMRD-build\ismrmrd.vcxproj]

This is resolved with a conda update hdf5.

[KrisThielemans]

Regarding ctest, need to call ctest in the SIRF-build with -C ${CMAKE_CFG_INTDIR} probably. However, this might then fail when using Makefiles as CMAKE_CFG_INTDIR might be set to . as opposed to empty (I checked that on the VM, both ctest -C and ctest -C . work fine though, so this should be safe). @rijobro, can you try this on Mac?

[KrisThielemans]

A few more fixes have been incorporated. All the ctest problems have now been fixed.

The above mentioned DLL problem was related to both FFTW and boost. dumpbin (part of the VS Toolkit) gave

 dumpbin /dependents _pygadgetron.pyd
    boost_filesystem-vc140-mt-1_63.dll
    boost_thread-vc140-mt-1_63.dll
    boost_system-vc140-mt-1_63.dll
    ismrmrd.dll
    libfftw3f-3.dll
    hdf5.dll
    ....

where I cut system libraries. Any DLLs in INSTALL/bin (such as ismrmd.dll) would be picked up if that's included in the PATH. I had to do the following (in Powershell):

 $Env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\bin"
 $Env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\FFTW"
 $Env:Path += ";c:/Users/krisf/Documents/devel/boost_1_63_0/lib64-msvc-14.0/"
 $Env:PYTHONPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python"
 $Env:MATLABPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\matlab"

(The FFTW line would not be necessary when using a system-version presumably).

As an alternative, I guess we could copy the libraries in bin (ugly) or force static linking (probably best really).

Sadly, I still get a python crash when just loading an MR.AcquisitionData object (with filename). I guess a conflict between DLLs or something.

For MATLAB, I still have problems presumably also related to DLLs

>> [notfound, warnings] = loadlibrary('mgadgetron')
Error using loadlibrary
There was an error loading the library
"C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\matlab\mgadgetron.mexw64"
The specified procedure could not be found.

Caused by:
    Error using loaddefinedlibrary
    The specified procedure could not be found.

[KrisThielemans]

• let CMake abort if 32bit build and say to give generator

[KrisThielemans]

Closing this as very outdated. Updating #197 instead