Closed nagisa closed 8 months ago
Could also go the windows-bindgen route, I suppose?
Would be nice to get this or #136 released to avoid duplicate dependencies downstream.
Thanks for the reminder. Just updating the dependency we have right now seems reasonable enough until we figure out a good way forward.
1 Mar 2024 14:09:53 Dirkjan Ochtman @.***>:
Could also go the windows-bindgen[https://crates.io/crates/windows-bindgen] route, I suppose?
Would be nice to get this or #136[https://github.com/nagisa/rust_libloading/pull/136] released to avoid duplicate dependencies downstream.
— Reply to this email directly, view it on GitHub[https://github.com/nagisa/rust_libloading/pull/125#issuecomment-1973077138], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAFFZUQCDNINQY2EX45MVE3YWBVY7AVCNFSM6AAAAAAZG6FH2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGA3TOMJTHA]. You are receiving this because you authored the thread. [Tracking image][https://github.com/notifications/beacon/AAFFZUUONPNHZSMVD747CZDYWBVY7A5CNFSM6AAAAAAZG6FH2SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVTLCJE.gif]
So, bumping windows-sys is not as trivial as may seem. At least one complication is that it has increased the MSRV to 1.56.0 due to use of edition 2021. I've been careful to not release versions of libloading that bump MSRV without also making a breaking release. This has been alright so far, as these bumps always coincided with other breaking changes, but this time it is not the case. That said, 1.56.0 is old enough that I can justify to my brain a patch bump with a MSRV break.
That said, its been a great opportunity to switch to windows-targets anyway...
Looks nice!
Is there a windows-targets
dependency missing from Cargo.toml
?
Its there; looks like there is something else going on. Its fine, I'll figure it out.
This results in a smaller dependency tree for the users and a slightly less maintenance burden for me (I won’t be losing any sleep over outdated dependency now!)
I have chose to make this a patch-point release. I believe this is an entirely compatible release –
LOAD_LIBRARY_FLAGS
is the same typedef to u32 before and after.HMOODULE
is the sameisize
, etc. The negative is that documentation now displays method types with resolved type names (i.e.isize
instead ofHMODULE
) which is not great. I would love to make tyese newtypes, but that's gonna need to wait for a breaking change.