Closed Berrysoft closed 1 year ago
Do you have a way of including this build in the CI?
I will try to include it. And by the way, cargo-clippy
fails because of uninlined_format_args
. Maybe you need to turn it off because it's very annoying:)
@mulimoen I've added a job to test this crate with MSYS2.
The clippy lints should be fixed in a separate PR, I think clippy supports rust_version
which would prevent MSRV trouble in the future. We need a bump in MSRV for that...
The package updated just now, and the dll name now changes with the soversion. Should we use pkgconf
in that case, instead of hard-coding the dll name manually?
The new test passed.
I have not used a windows system in ages. I think you are a better judge of whether pkgconf
will be more or less suprising for the developers using this library
MSYS2 provides pkgconf
of course, and vcpkg
, the Microsoft-banded C/C++ package manager, also provides pkgconf
affairs. I have also noticed that some other bindings, for example, libgit2 and openssl also use pkgconf
to find libs.
openssl-sys
only uses pkgconf
for Windows GNU target. I think I can follow this approach.
I added pkg-config support for all windows target because the gnu and msvc targets all supports pkg-config, and (maybe a bug?) they cannot be dealt separately. (When targeting GNU, a MSVC target build script will also be built and executed.)
And for Windows target, I choose to trust pkg-config result and not checking the dll, because at first we wanted to avoid hard-coding the dll names with pkg-config, which could not provide the dll name either.
We know hdf5 localisation is difficult, especially on windows. Thanks a lot for doing this the proper way
Pkg-config for Windows support added. Now it should work with pkg-config, and if pkg-config is not installed, HDF5_DIR
would also work (if dll name hadn't been changed by MSYS2).
pkg-config
gives many paths like C:\msys64\mingw64\lib\..\bin
, so we need to canonicalize the path before querying it in PATH
. The paths in PATH
should also be canonicalized when comparing because canonicalize
would turn a path to a UNC path on Windows.
If there's still interest in moving this forward, it would have to be rebased on the latest master, now that 1.14 support is in and all the build failures etc have been hopefully resolved and fixed.
I've merged master but need approval to run CI.
@Berrysoft There's changelog conflicts so you might want to quickly rebase again.
It looks like your build ran on CI and failed: https://github.com/aldanor/hdf5-rust/actions/runs/5227987760/jobs/9440874079?pr=229
Because the version is 1.14.1.2
(I think we do parse 1.14.1-2
, like it looks on arch, but not this format)
I solved the conflicts and updated the regex. Now it should parse both kind of versions.
@mulimoen Looks good? Any comments from your side? Seems like mingw build now runs green again 1.14.1.2.
// @Berrysoft not to be picky, minor nit: in PRs you'd normally rebase your branch against the main one as opposed to merging, otherwise you end up with all those merge commits in main. No big deal though, I'll just squash-merge it.
Interestingly enough, this mingw run doesn't hit this problem https://github.com/HDFGroup/hdf5/issues/3091
I cannot reproduce this problem on my device either.
Weird with the 1.14.1-2 static build, can't see any obvious differences in the build flags. Looks good to go!
Now merged, thanks @Berrysoft
is_msvc
tobuild.rs
to determine target enviroment from env var instead ofcfg!
, to make cross-compile right. Here the term "cross-compile" also means targeting GNU with MSVC toolchain (which is very common).libhdf5-0.dll
orlibhdf5-310.dll
(see this commit: https://github.com/msys2/MINGW-packages/commit/205f329c0231d8046b8bb3a2f6dff787c6613347). I'm afraid we need to update the dll name every time MSYS2 updates it. I suggest usingpkgconf
to detect it in the future.msvc_dll_indirection
to MSVC only.