support 0.14 and 0.15 in main?

[nurpax]

Hi! I noticed that a recent change probably breaks Zig 0.14 support: cf20488

I realized that at this point when zig-0.14 is pretty solid as far as using Zig goes, maybe it'd not be such a bad idea to support both 0.14 and latest dev in main? This shouldn't be too hard to do with comptime ifs. It'd be possible to protect for this in CI too.

If there's not much opposition to this, I might volunteer some time to craft a PR that does this.

Personally I'd like to keep my projects on zig-0.14 because I was feeling a bit burnt out catching up to zig-dev before the 0.14 release. But OTOH, I'd like to pick up new ziglua versions occasionally.

[robbielyman]

if you're so inclined, definitely go for it! this reminds me that i should cut a 0.14 tag / branch following what ziglua did for previous Zig releases!

[robbielyman]

@natecraddock i created a zig-0.14.0 branch and added an 0.4.0 tag with a draft release. please feel free to make any changes to it!

[nurpax]

I sent a PR, let's see if it passes CI. I tested it locally on both 0.14 and 0.15.

I found this comment from ziggit that summarizes one reasonable approach to dealing with this: https://ziggit.dev/t/why-arent-mach-nominated-style-versions-offered-from-official-zig/8045/12?u=nurpax

If keeping both working in main becomes untenable, there's always the option to keep zig-0.14 support only in a separate branch that's not updated.

[natecraddock]

i created a zig-0.14.0 branch and added an 0.4.0 tag with a draft release. please feel free to make any changes to it!

Thanks for doing that! I have a small change I'd like to make. I'll try to get to that in the next day or so and then we can do the release

[nurpax]

@robbielyman Hi! I noticed that CI dropped 0.14 support. Did supporting zig-0.14 get too awkward? I can see that it gets complicated, but OTOH some users (well, myself) have decided to keep using zig-0.14 to reduce churn in my projects. Looks like this means I can't use a newer ziglua then.

[robbielyman]

Sorry for the abrupt shift! The "Writergate" merge also precipitated breaking changes in both the build system and standard library (which touches the automated file patching tool), so I guess a short answer is "yes, it got too awkward". I think a judicious use of comptime could at least in theory produce a build script that works for both master and 0.14. I don't feel particularly motivated to do that work myself, but I wouldn't be opposed to merging it!

[nurpax]

I won't promise anything, but I might take a crack at it. :) I read about the Writergate.. that seems like an endless source of churn. Seems like something that will keep on giving new build breaks..

I did notice the changes regarding patching. I wonder if an easier approach to patching would've been to simply take a full file copy of the changed files in the ziglua repo (as opposed to storing just the patches), and instead of dealing with patches one'd copy those files over. The diff is reproducible anyway by running diff against the original tarball release.

[nurpax]

LOL.. I was a little worried that the callconv changes would've been a dealbreaker, but actually it's doable:

fn compat_c() type {
    return if (builtin.zig_version.major == 0 and builtin.zig_version.minor < 15) .c else .C;
}

fn testfunc() callconv(compat_c()) i32 {
    return 0;
}

It's not pretty but it is what it is.

[nurpax]

Moved the discussion into a new issue #166. For the time being, supporting zig-0.14 seems pretty easy.