hdf5-rust icon indicating copy to clipboard operation
hdf5-rust copied to clipboard

Support vcpkg on windows

Open windelbouwman opened this issue 4 years ago • 4 comments

I tried to use this crate on windows in combination with vcpkg.

What I did was:

CMD> vcpkg install hdf5:x64-windows

But the build.rs file does not pickup this installation. Maybe we can re-use the pkg-config detection for this type of installation of hdf5?

Any ideas?

windelbouwman avatar Mar 08 '20 07:03 windelbouwman

Update:

I got this to work by setting the HDF5_DIR environment variable to the vcpkg install folder (e.g. c:\vcpkg\installed\x64-windows)

windelbouwman avatar Mar 08 '20 08:03 windelbouwman

I don't have a native win machine, only some vms, so it might be easier for you to add the integration? Currently, we check the registry for the official hdf5 installation and we check conda if requested -- might also check for vcpkg one as well (whose location you'll probably have to pull out of the registry).

I'm not sure about this - any windows users care to comment? (e.g. @timfish?)

aldanor avatar Mar 08 '20 14:03 aldanor

It's probably possible to add vcpkg support, but the build for hdf5-sys already complex and without testing in CI it could get broken without manual testing.

This is why I'm always keen for static builds from git sub-module.

  • They cater for the vast majority of use cases
  • The pinned version and build can be thoroughly tested on every platform in CI
  • Installing/building the crate is reliable and low friction
  • If users require another version, they always have the option to use HDF5_DIR, etc

For us, low friction is key. With our Cargo.toml pointing at the above static build fork, we can build our library on any platform or in CI very easily and supply basic instructions for others to do the same. ie:

  • Ensure you have Rust v1.x and CMake v3.x installed
  • Run cargo build

I tried this on a Raspberry Pi and it Just Worked™.

I would almost go as far as suggesting that building from the git sub-module should be the default, simply because it's guaranteed to work without any other configuration.

timfish avatar Mar 08 '20 16:03 timfish

There are unfortunately some drawbacks to making the static builds standard,

  • Increased compile time (primarily on first build)
  • Licensing (although this could work on an opt out basis, hdf5 has a quite liberal license)
  • Incresed binary size (although not as much when LTO is used)
  • Opting out of default features is a bit harder than opting in to a feature

magnusuMET avatar Mar 08 '20 21:03 magnusuMET