libusb
Windows artifacts from Github Actions
This would be easy to do for every OS if the workflow was refactored to use a matrix instead of entirely separate code for every condition. For example, https://github.com/tenacityteam/portsmf/blob/main/.github/workflows/build.yml
On each OS the artifact name is different (.dll/.so/.dylib) so with single matrix for different OS-s we'd have a bunch of ifs or an andditional variable, which I don't find to be cleaner nor more readable.
On each OS the artifact name is different (.dll/.so/.dylib)
You can just upload the whole installation directory as the artifact. That is useful for verifying that the installation procedure is working on different OSes.
Github actions are in place now for Windows, macOS and Linux. And yes it is good to keep the artifact.
Example from OpenOCD. https://github.com/openocd-org/openocd/blob/master/.github/workflows/snapshot.yml
On each OS the artifact name is different (.dll/.so/.dylib)
You can just upload the whole installation directory as the artifact. That is useful for verifying that the installation procedure is working on different OSes.
avrdude project is archiving both the build artifacts plus the executables. https://github.com/avrdudes/avrdude/blob/main/.github/workflows/build.yml
I actually had done this already in my other projects - that's not a problem for sure. As alwasy - it is only a question of time/efforts (at least for me).
#414 has been merged for Windows.
@Youw
I am not so sure if you want to keep artificats for other build. I think the Linux build does not help much as they will most likely not work for other distros or older version of the distros. Even the macOS build may not be that useful either.
In that case, only MinGW build may have some usage.
I think the Linux build does not help much
Agree.
Even the macOS build may not be that useful either
Actually, in theory - it would. Because macOS supports similar to Windows application distribution model, when you have you application/binary built once with all dependencies bundled and forward-compatible for at least several macOS releases, library like HIDAPI built once (with min macOS version specified build-time as once of the "standard" cmake arguments) - supposedly will work for tha same arch even for newer versionos of maOS.
But I don't think it is needed anyway, since HIDAPI is available over brew and it has formula "build from source" or "pre-built", and I think it is even possible to specify a branch if needed (or is it only "latest master"?).
only MinGW build may have some usage
I don't think so. First of all - there is multiple variations of MinGW itself (at least MinGW32 and MinGW64), not to mention similar but different Sygwin, etc. I've even hit issues with binary non-compatibility (of the import library) for different versions of MinGW.
There is also a different point: a pure C library built with no dependencies (like HIDAPI) may be used with any Windows compiler/linker, i.e. HIDAPI built with MSVC may be likned against MinGW application. The only thing that is needed - an import library, which is compiler-specific, but can be generated from .dll.
To be honest I don't remembre why I didn't close this issue after #414 merged. And I don't think anything else is needed right now.
To be honest I don't remembre why I didn't close this issue after #414 merged. And I don't think anything else is needed right now.
I agree with you.