Add VTK port

[albertziegenhagel]

Adds a port for the VTK framework (http://www.vtk.org/).

Resolves #22

[alexkaratarakis]

Sorry for the delay on this, we have been trying to resolve dependency issues (mostly qt5).
(e4ff363, dd6d1aa)

[ras0219-msft]

While trying to build this, I hit an issue with the interactions between VTK and HDF5.

82>d:\src\vcpkg\installed\x86-windows\include\H5public.h(152): error C2632: 'int' followed by 'int' is illegal (compiling source file D:\src\vcpkg\buildtrees\vtk\src\VTK-7.1.0\ThirdParty\netcdf\vtknetcdf\libsrc4\error4.c) 

Essentially, vtk's config.h defines ssize_t to be int, but HDF5 wants to typedef it to the same. This causes HDF5 to try to typedef int int;, which causes the above error message.

Some notes:

• Archlinux uses 7.1, but has disabled system HDF5 [1]
• I noticed that Ubuntu and Debian both have very out-of-date versions (5.X series) [2]
• Homebrew appears to build both without issues [3], though it's using HDF5 version 1.10 [4].

I think checking whether 1.10 fixes it is the best option, followed by an attempt to patch, followed by disabling system HDF5.

[1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/vtk
[2] https://packages.debian.org/source/wheezy/vtk
[3] https://github.com/Homebrew/homebrew-science/blob/master/vtk.rb
[4] https://github.com/Homebrew/homebrew-science/blob/master/hdf5.rb

[albertziegenhagel]

I could not reproduce this here (tried with a fresh and most recent version of vcpkg). I did build x64 instead of x86, which may be the difference. I will try to build it for x86 over the next night (qt5 really makes this take a while...).

I took a look into HDF5 1.10 and it looks like there are no changes in the code that detects and defines ssize_t. I think on linux or macOS this issue does not arise since they have ssize_t defined in <sys/types.h> so that HDF5 does not try to typedef ssize_t itself.

Could you point me to the code where VTK defines ssize_t? The only place I could find such a line in a file named config.h was in the config.h of VTKs own NetCDF. Maybe adding a port for NetCDF and then use system NetCDF in VTK can fix that issue.

[albertziegenhagel]

I rerun the test and indeed the issue occurs to x86 builds only and is related to netCDF.

I started to write a port for netCDF but it seems @ras0219-msft was faster than me ;)

Please let me know if there is anything I can help with.

[ras0219-msft]

Thanks for coming back to this :).

I didn't want to respond empty-handed, so I went ahead and ported netCDF-c and netCDF-cxx4. Along the way, some changes were needed to szip and hdf5 as well. Unfortunately, VTK relies on the 5 year old, deprecated netCDF-4.2 C++ APIs, so that direction wasn't fruitful.

I've since attempted to patch ncconfig.h.in by just commenting out the #cmakedefine ssize_t, however I'm now having a strange issue that VTK appears to be linking the HDF5 dll directly instead of the import lib.

[ras0219-msft]

I additionally had to override the HDF5 library detection -- due to a bug in CMake's builtin FindHDF5.cmake, VTK was linking the DLL.

Could you try out the merged version and make sure it works on your machine?