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.

[booniepepper]

I'm still interested in this, but between job hunting and holidays I haven't been able to make the time yet.

IDK if this helps a lot of people, but one note for Zig project owners is that it's possible to support a range of Zig versions even with the breaking changes. Here's an example of me adding Zig 0.10.1 support back into a project that was already upgraded to 0.11.0: so-dang-cool/dt@f58602c

[icp1994]

Now that llvm17 is merged, you can start working on zig-0.11 if you want.

[tranzystorekk]

zig unfortunately pins LLVM version strictly, and 0.11 wants LLVM 16

[icp1994]

Ah right, forgot it's not forward compatible either.

[Anachron]

So we have to wait for zig0.12 and hope it uses llvm17? What if it uses 18? This is ridiculous (not our fault though).

Maybe zig has their own Compiler until then.

[voidbert]

So we have to wait for zig0.12 and hope it uses llvm17? What if it uses 18? This is ridiculous (not our fault though).

Maybe zig has their own Compiler until then.

Currently, C, x86 and ARM backups are on the works. Zig is also removing the hard dependency from LLVM: it'll output IR which can then be compiled by LLVM, and it won't need libllvm anymore. I do not know, however, if the produced IR will require a specific LLVM version.

[Calandracas606]

I'm already working on llvm18 #48661

Hopefully it will ready for zig0.12

[Anachron]

Normally it takes a lot of time until all packages are ready and then zig0.12 will probably be old again.

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