Windows artifacts from Github Actions

Youw commented

2021-08-02 06:53:06 -05:00

(Migrated from github.com)

See https://github.com/libusb/hidapi/issues/298#issuecomment-890687866

Be-ing commented

2021-08-03 10:03:08 -05:00

(Migrated from github.com)

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

Youw commented

2021-08-12 03:47:05 -05:00

(Migrated from github.com)

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) so with single matrix for different OS-s we'd have a bunch of `if`s or an andditional variable, which I don't find to be cleaner nor more readable.

Be-ing commented

2021-09-03 23:24:07 -05:00

(Migrated from github.com)

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.

> 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.

👍 1

mcuee commented

2022-05-03 21:08:56 -05:00

(Migrated from github.com)

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

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

mcuee commented

2023-03-19 22:35:55 -05:00

(Migrated from github.com)

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

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

Youw commented

2023-03-20 05:36:49 -05:00

(Migrated from github.com)

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

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

👍 1

mcuee commented

2023-05-01 08:58:02 -05:00

(Migrated from github.com)

#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.

#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.

Youw commented

2023-05-01 10:18:43 -05:00

(Migrated from github.com)

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.

> 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`](https://formulae.brew.sh/formula/hidapi) 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](https://sourceforge.net/p/mingw-w64/wiki2/Answer%20generation%20of%20DLL%20import%20library/) from .dll.

👍 1

Youw commented

2023-05-01 10:23:23 -05:00

(Migrated from github.com)

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.

👍 1

mcuee commented

2023-05-01 22:28:02 -05:00

(Migrated from github.com)

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.

> 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.

Rows
Columns

Windows artifacts from Github Actions #315