0.14.0 is one month out

News
1

Great time to upgrade and make sure your projects’ issues get addressed before the tag is cut!

https://ziglang.org/news/what-to-expect-from-release-month/

53 Likes
2

Damn, I haven’t heard of Infected Mushroom for ages :star_struck:

4 Likes
3

Apart from the initial shock
Screenshot at 2025-01-17 20-59-59
upgrading went smoothly for me (I just had to fix 7 lines, the error was duplicated by comptime)

3 Likes
4

That’s a tricky one. Arguably those errors should be deduplicated based on AST node, but sometimes it is handy to get multiple errors for different comptime instantiations.

1 Like
5

Is there a changelog out? I looked around but couldn’t find any.

7

Wait until February 17-th.

8

You can get a preview of it by looking at the merged PRs with the release notes label:

https://github.com/ziglang/zig/pulls?q=is%3Apr+label%3A"release+notes"+merged%3A>2024-06-06

7 Likes
9

my only stumbling block was a tab character being present in a struct declaration. “expected type expression found invalid token” without any pointer what that invalid token might be. I ended up running expand(1) on the source after finding an issue on gh et voila …

Aside of that, I find build changes such as dropping b.host (after it had been deprecated) or changing defineCMacro (in receiver, name and fn signature) to be discoverable hard. I’ll peruse squeek’s merge PR list and see if that would’ve helped me … and I can just say that I didn’t find this. I’m getting better at using the tools at my disposal to tackle such upgrade problems, yet find it needlessly abrasive. I suppose a “living” changelog with those upgrade howtos like last time would be nice to have.

1 Like
10

Jakub decided to move on to other things

:cry:

11

But still in Zig. :slightly_smiling_face:

2 Likes
12

Btw, last Zig nightly causes a very mysterious CI pipeline fail in sokol-zig, and only on Windows (e.g. the zig compiler just fails silently with exit code 116 - scroll to the top to see the problem):

…but it looks like only one of the samples have that error (which makes it even a bit more scary).

I haven’t investigated yet, just writing this here because it looks like the Zig-project CI is green on Windows (so probably not a known issue yet).

PS: a followup build with exactly the same Zig version worked, and I also cannot reproduce on my Windows laptop. I’ll keep an eye on it.

13

Hmm that’s a great point. The purpose of the release notes are to help make these changes more discoverable, but it defeats the purpose if I suggest to try upgrading a month in advance, doesn’t it?

:thinking:

3 Likes
14

A little. On the other hand, you can of course just try out whether or how far the compiler runs. But that depends on the type and size of the project. So a bullet point list of what has changed in this regard would be beneficial.

2 Likes
15

I’m seeing quite a number of problems caused by the loss of anonymous structs. The following is in the build file of ziglua:

    const lib_opts = .{
        .name = "lua",
        .target = target,
        .optimize = optimize,
        .version = switch (lang) {
            .lua51 => std.SemanticVersion{ .major = 5, .minor = 1, .patch = 5 },
            .lua52 => std.SemanticVersion{ .major = 5, .minor = 2, .patch = 4 },
            .lua53 => std.SemanticVersion{ .major = 5, .minor = 3, .patch = 6 },
            .lua54 => std.SemanticVersion{ .major = 5, .minor = 4, .patch = 6 },
            else => unreachable,
        },
    };
    const lib = if (shared)
        b.addSharedLibrary(lib_opts)
    else
        b.addStaticLibrary(lib_opts);

No good way of fixing this aside from replicating the struct. addSharedLibrary() and addStaticLibrary() accept different structs so you can’t just add a type to lib_opts. You can set the type of lib_opts based on shared either since it’s is runtime.

1 Like
16

Try using this trick, I’ve used it to great success:

const lib: *std.Build.Step.Compile = switch (shared) {
    inline else => |x| switch (x) {
        true => std.Build.addSharedLibrary,
        false => std.Build.addStaticLibrary,
    }(b, .{
        .name = "lua",
        .target = target,
        .optimize = optimize,
        // ...
    }),
};

Though I would probably prefer if there was a b.addLibrary(link_mode, options) function.

8 Likes
17

b.addXLibrary() is just a thin wrapper around std.Build.Step.Compile.create(). You can get the equivalent to what you’re after by hitting that directly. I use this whenever creating a library:

    const linkage = b.option(std.builtin.LinkMode, "linkage", "Specify static or dynamic linkage") orelse .dynamic;
    var lib = std.Build.Step.Compile.create(b, .{
        .root_module = .{
            .target = target,
            .optimize = optimize,
            .pic = if (linkage == .dynamic) true else null,
        },
        .name = "mylib",
        .kind = .lib,
        .linkage = linkage,
    });

Note that this is all 0.13 still as I haven’t started porting my projects, but this appears to still be the case in master. Have a look at the addStaticLibrary vs addSharedLibrary functions to convince yourself this is equivalent:

1 Like
18

This seems like an indication of a flawed build system API. Feel free to open an issue proposing combining addStaticLibrary with addSharedLibrary if you can’t find an existing one.

19

…and it just happened again (the Windows compiler ‘crash’ on Github CI). Wrote a ticket now: Random(?) compiler error codes on Windows CI runners (seen error codes 5 and 116 so far) · Issue #22567 · ziglang/zig · GitHub

20

thanks! appreciate the report.

1 Like
21

All my projects go through except the doc