Fix binary releases

[almarklein]

Closes #91

• Enables the release builds also for non-tags (but don't upload artifacts).
• Fix the builds for Windows by installing llvm and setting LIBCLANG_PATH.
• Disabling Linux32 build, see note below.
• Also include webgpu.h in the zipfile.
• Re-implement wgpuGetVersion, see note below.

The Linux32 release build is broken, so I disabled it. For us (wgpu-py) this is not a problem, because we cannot provide binaries for 32bit Linux anyway (because of one of our other dependencies). In case someone wants to fix this, the reported error is:

error[E0308]: mismatched types
   --> src/lib.rs:263:21
    |
263 |             window: x11.window as u64,
    |                     ^^^^^^^^^^^^^^^^^ expected `u32`, found `u64`

edit --> This is now fixed

I changed wgpuGetVersion to take its version from environment variable WGPU_NATIVE_VERSION, which we set in the CI. The version will be 0 if that variable does not exist. This ensures that the reported version matches the tag (the wgpu_get_version in v0.7.0 reports 0.6.0 ;) ). This means the version in Cargo.toml is irrelevant.

The version must be ints separated by dots. These are mapped to the 4 bytes of an uint32.

[kvark]

Thank you!

window: x11.window as u64,

Would you mind just doing x11.window as _?

[kvark]

Why do we need to build this on every build?

[almarklein]

I think it makes sense to do so. Otherwise we'll only find out if it's broken when trying to push a tag :) Plus it adds some extra coverage (e.g. win32 and linux32).

[kvark]

We should detect any breakages (that are reasonable to detect) in the other job, the regular test job.

[almarklein]

Maybe we could remove some of the other builds to avoid duplication. E.g. only the nightly builds include glfw in the compilation, so the stable builds do nothing that the release-builds does not already do.

[almarklein]

Any specific reason why the release-builds cannot also function as a test-build? :)

[almarklein]

The main purpose of the release-builds is to create the binaries. In that process they (obviously) build the project, which in itself is a test - in fact the builds in the test-jobs (currently) don't do much more than performing a build :)

So one argument for running these on every build is that them working can be seen as a minimal signal that all is well, and the test-jobs can be used for more advanced tests. A second argument is that if we only run the release-builds when pushing a tag, it's easy for them to become outdated (and you only find out when pushing a tag).

Anyway, if you prefer to keep these more separate, I'll put back the if. I could prepare another PR to add test builds for win32 and linux32.

[kvark]

ll is well, and the test-jobs can be used for more advanced tests

One problem here is that the tests only care about the debug builds, reasonably assuming that release will have to build successfully if debug is fine. So if you combine it with the release job, we'll end up building both release and debug, wasting CI time. This isn't a problem right now, given the low rate of PRs, but it's not scaling well.

A second argument is that if we only run the release-builds when pushing a tag, it's easy for them to become outdated (and you only find out when pushing a tag).

They got outdated now because we have a major change in the project (replacing cbindgen by bindgen). It's not supposed to happen often, and even when such breakage occurs, we can fix it as we see it: a breakage in the release job doesn't affect anybody.

I.e. the point of a CI check is to make sure that no bad code accidentally gets checked in. It's important be cause later the bad code will accumulate, and it may be hard to see when exactly things broke. If all we have broken is a release job, then the breakage is limited to this one tiny build script, which can be fixed or even rewritten.

If I understand correctly, what you want is coverage for 32-bit platform builds. This is reasonable, even if niche. How do you feel about the following proposal: we add a 3rd job to build these targetr, but we'll only run it on master merges (not any PRs). So we'll know quickly enough if something is broken, but we aren't going to stress the CI to build them on each PR iteration.

[almarklein]

Fair points. Ok, I added the if back so they only run on tag pushes. I'll have a look at the test-builds in another PR. I like the idea of running certain builds only on pushed to master.

[kvark]

Thank you! Let's adjust the comment as well. It currently says that the release builds happen all the time.

[almarklein]

Done!

[almarklein]

Would you mind just doing x11.window as _?

Thanks for the suggestion. I was expecting/hoping for the fix to be simple.

[kvark]

A bit surprised we are running make package on CI for all changes. Is this a mistake?

[kvark]

This was in Windows Stable, and it rebuilds everything...

[almarklein]

It looks like that has been the case even before the release builds were added. My guess would be that the make package did less at the time, so it made for a good test run. Shall we fix that in a next CI-refactoring PR, so this pr's focus remains on fixing the releases?

[almarklein]

I just pushed a tag to create a new release.