Release new version

[z3ntu]

Should be done as soon as a few important patches have been applied.

Also probably the new version shouldn't be called 0.8.0 as apparently Fedora + derivatives(?) call commit d17db57 0.8.0 as listed on https://repology.org/project/hidapi/versions , so I'd start with 0.9.0 or similar

[Qbicz]

I will prepare the release. I would like to attach built libraries, what do you think about it (at least for Windows)? In the future we will have them available from CI: https://github.com/libusb/hidapi/issues/6

[Qbicz]

Can you review the release candidate 1? https://github.com/libusb/hidapi/releases

If you agree it's ok, I will create 0.9.0.

[Qbicz]

Especially testing on macOS and FreeBSD would be welcome if you have access to these OS. @todbot @Youw @z3ntu

[z3ntu]

I've noticed that you didn't update the version number in configure.ac so it was still displayed as 0.8.0-rc1.

Tested on FreeBSD (or GhostBSD to be precise - a FreeBSD derivative) and works fine. And I'm waiting for my macOS install to update Xcode because homebrew complains it's too old...

[Youw]

macOS and FreeBSD

Don't have those platforms right now.

As for Windows - if we release .dll binaries - we should also provide .lib import libraries. Also, I'd rather release win.zip archive with:

• x86\hidapi.dll
• x86\hidapi.lib
• x64\hidapi.dll
• x64\hidapi.lib

Or win64.zip + win32.zip.

[Youw]

One more note regarding Windows: the binaries attached, depend on MSVC2015 runtime. That sounds a bit heavy for a small pure C library. I suggest build with ~/MD~ /MT MSVC flag, so compiler runtime is embedded. Or, at least, explicitly state that there is a dependency.

[z3ntu]

Finally tested it on macOS 10.14.5 and it works fine there too :) https://github.com/z3ntu/homebrew-core/commit/b8909af186310cd5d08ff220c3ce56c7226f384f

[Qbicz]

Thank you for review and for testing! I agree with bundling win.zip with .lib as well as .dll.

Having compiled with /MD or /MT, the dll still depends on MSVC runtime. I see API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL and others like that in Dependency Walker, and the size of hidapi.dll has not grown to include the C runtime. Of course I compile in Release mode so there is no dependency on any debug libraries.

@Youw As I understand it, /MT (current dll in 0.9.0-rc1) mean to link the C runtime statically, and /MD means to link runtime dynamically and use the C runtime installed on target machine. So maybe checking in Dependency Walker is not correct way of checking this?

[Qbicz]

I updated version in configure.ac and uploaded zip with .dll and .lib in directories x86 and x64.

Tested latest version on Ubuntu x64 Linux with hidraw backend, attached DLLs tested for Windows x64 and Windows x86.

[Qbicz]

Attached DLLs are compiled with /MD.

[todbot]

I have macOS and FreeBSD. Basic testing on macOS 10.14.5 looks good. FreeBSD 11.2 building works from bootstrap -> autoconf -> make -> compiling hidapitester (my app) -> hardware HID send/receive

[Youw]

@Qbicz, yes you understand correct, some details

Sorry, I mistype the first time - I mean /MT, so we do not have dependencies on VCRUNTIME*.dll, api-ms-win-crt-*.dll

It's been a while since I tried it the last time for .dll, maybe you need actually specify /LD, and make sure, to omit the /MD flag

also, if you have a MSVC project - you can check your .vcxproj file (as text), and search for <RuntimeLibrary> key; make sure it is:

<RuntimeLibrary>MultiThreaded</RuntimeLibrary>

as an opposite to:

<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>

which would cause having those .dll dependencies

[Qbicz]

Since we have tested Windows, Linux, Mac and FreeBSD, I will proceed to 0.9.0.

@Youw I will stick to /MT (MultiThreaded, without state sharing).

[Qbicz]

Done https://github.com/libusb/hidapi/releases

[z3ntu]

I'll send out-of-date requests / patches to Arch Linux (updated!), Alpine Linux (PR merged!), Void Linux (PR merged!) & Homebrew (PR open).

Maybe someone else can handle Debian (which will cover the many distros based on Debian) Fedora & openSUSE would also be important targets

[z3ntu]

Btw as you might have noticed, I've opened draft pull requests for two "new" platforms, OpenBSD and Haiku. Both already have hidapi in their repos but with custom patches that would be nice to integrate into the main codebase.

[Qbicz]

Thanks @z3ntu! I have sent a report to Debian.

[z3ntu]

Exherbo (whatever that distro is) and NetBSD also have updated the package to 0.9.0, I'll prepare a PR with the patches NetBSD have in their ports.

[z3ntu]

Debian has 0.9.0 in bullseye & sid and Homebrew has also merged the PR

[z3ntu]

I've also opened a "request" at openSUSE: https://build.opensuse.org/request/show/717190# (I hope that's the right place^^)

I won't do Fedora because they require a CLA to be signed to submit a PR. Fedora has already updated in Rawhide 9 days ago :)

[z3ntu]

openSUSE has 0.9.0 in Tumbleweed (their rolling release version) now. msys2/mingw has 0.9.0 since about a month (doesn't get displayed correctly on repology)

Looking at https://repology.org/project/hidapi/versions now shows Solus, PLD Linux (polish distro based on RHEL), SlackBuilds (Slackware), PCLinuxOS, OpenWRT, OpenBSD, NixOS, Hyperbola, Gentoo, FreeBSD, DragonFlyBSD (and another bsd with an extra patch, but this one is small, I promise ;) ), Cygwin, AOSC & ALT Linux and a bunch Ubuntu/Debian derivatives.

I think they are all small enough that we can ignore them :wink: And they will probably update themselves, as some distros have done already.

[z3ntu]

I'd say we close this now. :tada: