Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support vcpkg on windows #84

Open
windelbouwman opened this issue Mar 8, 2020 · 4 comments
Open

Support vcpkg on windows #84

windelbouwman opened this issue Mar 8, 2020 · 4 comments

Comments

@windelbouwman
Copy link

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
Copy link
Author

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)

@aldanor
Copy link
Owner

aldanor commented Mar 8, 2020

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?)

@timfish
Copy link

timfish commented Mar 8, 2020

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.

@magnusuMET
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants