Updating Zig to 0.11.0

[booniepepper]

Opening this issue to discuss an upgrade of Zig from 0.10.1 to 0.11.0

Zig 0.11.0 was released yesterday: https://ziglang.org/download/0.11.0/release-notes.html

It's backwards-incompatible with 0.10.1 which should be no big surprise. What I'm
interested in talking about is how to handle the transition. A lot of Zig software
has been tracking the changes for 0.11.0 in particular because it came with some
package management abilities that really made owning a zig-built library or executable
a lot cheaper.

Is it acceptable to have two versions of Zig in void-packages while projects are transitioning?

[booniepepper]

cc @ifreund

[icp1994]

For a start, it requires llvm v16.x which will take a non-trivial amount of effort to get into Void repos. It's highly likely that by the time the latest llvm hits the repos, the existing zig packages would have already migrated to zig v0.11.x

[booniepepper]

That makes sense to me, thanks!

[voidbert]

@icp1994 Are there any plans to package LLVM 16? Packaging something as massive as LLVM is a massive endeavor (see #40821, for LLVM 15), and involves updating many packages that depend on LLVM (Zig, for example). With LLVM 17 just around the corner in September (https://llvm.org/), is it worth it to make an effort, or should Void just skip v16 and go straight to 17?

[icp1994]

Honestly, I don't know what the best strategy is. If you are asking for zig only, iirc each major version of zig is compatible with only one major version of llvm so I think if you skip llvm v16 you cannot build zig v0.11.x. But I feel only zig (and related softwares) being blocked on it might not cut for the effort of a llvm update. For example, the last time llvm was updated, rust was also blocked on it.

[voidbert]

@icp1994 The best strategy would be for the folks at LLVM to make their software backwards / forwards compatible, but we all know that's not gonna happen. Nevertheless, Zig will be coming out with some alternative backends (C, x86, ARM and LLVM bitcode, instead of linking to LLVM libraries). This would remove the mandatory LLVM dependency, making a zig update just a version bump + new checksum.

[booniepepper]

For what it's worth, in Nix the strategy is to import multiple versions of these foundational things like LLVM. They also do it with Zig since they have software that needs Zig 0.9, 0.10, and now 0.11. Applications and tools and etc tend to only have a single rolling version

[voidbert]

@booniepepper Void already maintains different versions of packages like LLVM (https://github.com/void-linux/void-packages/tree/master/srcpkgs/llvm12, for example). The problem is that there aren't enough human resources to package and maintain all versions of LLVM. Between 12 and 15, there are no other LLVM versions on the repos, for example.

[booniepepper]

Looking at the patches and script... Yeah I see how that can be an adventure to set up

[tranzystorekk]

Void already maintains different versions of packages like LLVM

To be precise, we keep the previous llvm version for its libllvm shlib, but all the other subpackages like clang have always had just one version at a time.

[Anachron]

I hope we will find some volunteers to tackle this task.
While I am not skilled enough to do this myself, I would volunteer for testing.

[voidbert]

For anyone here that needs Zig 0.11, even if it doesn't get added to Void's repos, you don't need to build it from source. Zig's prebuilt binaries are statically linked, working perfectly on both musl and glibc systems (I tested it myself).

[booniepepper]

Hmmm maybe that's the thing to do. I was also considering packaging my zig-built projects from binaries too, but I didn't know if that would be frowned upon

[Anachron]

Sadly binary releases are nearly impossible to get into Void Packages, but there could maybe be an exception as long as we dont have LLVM16 yet?

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.