Created attachment 263338 [details]
zig version bump to v0.15.1

attached a diff to bump zig version up to v0.15.1 release

Tried the v0.15.1 patch and it got thumbs up from me. The current ports version (0.14) fails with simple hello world example from zig website for me. 0.15.1 works.

Ideally devel/zls should be updated at the same time though.

Please sync update to 0.15.1 with update of devel/zls to 0.15.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289635

Comment 4 Vladimir Druzenko 2025-09-19 13:24:23 UTC

Unnecessary: CONFLICTS_INSTALL=      zig0*
$ grep zig MOVED
lang/zig011||2024-06-12|No consumers in ports
lang/zig-devel||2024-06-13|Older than lang/zig and no consumers in ports
lang/zig010|lang/zig|2025-08-31|Has expired: Old zig implementation, no consumers in ports
$ ls -d lang/zig*
lang/zig

Comment 5 Vladimir Druzenko 2025-09-19 23:54:41 UTC

Build fine for me in poudriere 14.3 amd64.

Comment 6 Vladimir Druzenko 2025-09-30 02:50:19 UTC

Rodrigo, are you still want to commit this update?

Comment 7 Jan Beich 2025-10-02 01:46:47 UTC

Did you test *all* consumers? "git grep -lF :lang/zig | wc -l" returns 8 ports. All of those used to break on "minor" updates in the past. Only "patch" updates were safe e.g., 0.12.0 -> 0.12.1.

If you can't fix consumers (like bug 279604 or bug 286105) at the same time consider forking lang/zig (like bug 273124 or bug 278570). I no longer maintain anything Zig-related, so can't help with the former. The latter (forking) is handled similar to a port rename: copy directory, connect in category/Makefile, add PKGNAMESUFFIX + PORTSCOUT and modify COMMENT, set up CONFLICTS_INSTALL, adjust category/port in reverse dependencies.

ports-mgmt/zig2tuple fails to build with zig 0.15.1, but the github source shows an already existing 0.15.1 branch. I was able to compile and run that successfully, but as its on a branch you can't just set GH_TAGNAME to the SHA.

Comment 9 Rodrigo Osorio 2025-10-23 17:40:32 UTC

(In reply to Vladimir Druzenko from comment #6)
Hi Vladimir,

Thanks for the heads-up ;)
Yes I will still working on that one.

I was working on 0.15.2 (wish I saw this PR first!)

The following consumers pass poudriere testport with 0.15.2:

    biology/vcflib
    sysutils/ncdu2

The following consumers fail:

    astro/mepo
    audio/linuxwave
    devel/zls
    games/xtxf

I haven't investigated them too closely. 0.15 introduced a bunch of breaking changes since 0.14. I looked at astro/mepo a bit, and there's a patch series to update it to 0.15: https://lists.sr.ht/~mil/mepo-devel/patches/62061 https://lists.sr.ht/~mil/mepo-devel/%3C20250821020031.28035-2-lauren@selfisekai.rocks%3E

Presumably devel/zls should be updated in lockstep with zig version. I haven't looked at the other two.

I think this will continue to be a problem while Zig is pre-1.0. It seems like we'd be better off with distinct minor versions, e.g. zig-014, zig-015 etc?

Created attachment 264832 [details]
zig 0.15.2 with build improvements

(In reply to Pat Maddox from comment #10)
xtxf (0.11.4) is ready for 0.15

(In reply to Pat Maddox from comment #10)
oh snap, I forgot to cut the release

Comment 14 Rodrigo Osorio 2025-10-28 14:40:04 UTC

Comment on attachment 263338 [details]
zig version bump to v0.15.1

Mark patch to 0.15.1 obsolete, replaced by 0.15.2 which is the last version

Comment 15 Rodrigo Osorio 2025-11-01 18:22:48 UTC

Hi Pero Oršolić,

As said before, the patch 264832 "zig 0.15.2 with build improvements"
woks as expected on poudriere to build zig, but the test target fails.

Adding missing dependency (TEST_DEPENDS=  linux_base-rl9>=9.2:emulators/linux_base-rl9)
helps but don't solve the problem.
This is probably not required, but I need your feedback before committing the changes for this port.

All the best
-- rodrigo

Hi Rodrigo Osorio,

In my opinion is better to have imperfect solution than no solution at all :)
I'll look into updating consumers later, when I got more free time.

What do we think of forking to have 0.14 and 0.15 versions? Zig is making lots of breaking changes, consumers aren't necessarily keeping up.

(In reply to Pat Maddox from comment #17)
Whatever gets me into the kitchen))) Tho the consumer count is pretty low for a fork.

(In reply to charlesrocket from comment #18)

Also, when people commit ports that depend on a fast moving, WIP language, they better keep their sleeves up. I'm sure most people interested in Zig would want the latest version, not some version in which official docs and examples don't even work. Since Zig supports FreeBSD, you can always manually install what fits your needs. Sorry I can't help more with the practical matters for the time being.

(In reply to ktullavik from comment #19)
True, but some upgrades might require a lot of time, depending on the size of the codebase. FreeBSD binaries is a new thing, tho—just recently you would have to build your own.

I updated to zig-0.15.2 with the above patch. My setuo with vscode and zls-0.15 (also patch above) continued to work. I deinstalled and rebuilt zls just to make sure, and it still works. These are both latest releases, and should work together.

In my opinion, it's the two ports that matters. All else is premature and should require diligent maintenance or be left behind.

Created attachment 265599 [details]
x11/waylock

x11/waylock zig 0.15

Created attachment 265600 [details]
x11-wm/river

x11-wm/river zig 0.15

Created attachment 265601 [details]
games/xtxf

games/xtxf zig 0.15

Created attachment 265602 [details]
lang/zig014 fork

Created attachment 265603 [details]
consumers on zig 0.14

My uploaded patches are continuation of:
1) Pat Maddox' zig 0.15.2 update (this thread)
2) ktullavik's zls update https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289635

3) consumers updated to Zig 0.15.x:
sysutils/ncdu2 - not updated, compiles and runs with Zig 0.15.2, already at latest release
x11/waylock
x11-wm/river
games/xtxf

4) zig 0.14 forked to separate port. This is a temporary solution as some consumers are not yet ready for 0.15. PORTVERSION not dumped as I think that they don't need rebuild - older pkgs should continue to work.
audio/linuxwave - Not ready for Zig 0.15. Latest commit in main won't compile with 0.15
biology/vcflib - Upstream not ready for Zig 0.15, needs Zig 0.14. Tried to upgrade it but gave up. Patched build.zig for 0.15, but not vcf.zig
astro/mepo - upstream has patches for 0.15 but they are not merged. After appyling them (with small fixes) the project still won't build with Zig 0.15

If someone wants to continue work for vcflib and mepo and upgrade them to Zig 0.15, I will upload wip*.patch-es. Otherwise use Zig 0.14 with them.

Comment 28 Jason W. Bacon 2025-11-23 23:03:30 UTC

Patch for biology/vcflib to use zig014 approved.  I'll have a look at upgrading vcflib after the zig commit.  This port has always been difficult.  My progress will be available at https://github.com/outpaddling/freebsd-ports-wip.

Whats the blocker right now?

Comment 30 Rodrigo Osorio 2025-11-30 08:48:03 UTC

(In reply to charlesrocket from comment #29)

I am the blocker, sorry for the delay. I will handle it ASAP.

Comment 31 Rodrigo Osorio 2025-12-01 10:12:44 UTC

slowdive,

games/xtxf 0.11.5 has an issue and can't be build in poudriere

===>  Building for xtxf-0.11.5
/wrkdirs/usr/ports/games/xtxf/work/xtxf-0.11.5/build.zig.zon:12:20: error: unable to connect to server: CertificateBundleLoadFailure
            .url = "https://github.com/00JCIV00/cova/archive/3fa729ccf582a4c818402019a579f1c5caf90fd3.zip",
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/games/xtxf/work/xtxf-0.11.5/build.zig.zon:16:20: error: unable to connect to server: CertificateBundleLoadFailure
            .url = "https://github.com/charlesrocket/ghext/archive/refs/tags/0.7.4.tar.gz",
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** Error code 1

Stop.

(In reply to Rodrigo Osorio from comment #31)
Looks like offline fetch issue. Maybe it is due to the old hash format in deps?

(In reply to charlesrocket from comment #32)
hmm, I guess hashes are not the issue, `zig fetch --save` does not produce any changes.

(In reply to Rodrigo Osorio from comment #31)
Oh looks like I found it. Cova was updated in the latest release, but its hash in the port is old.

(In reply to Rodrigo Osorio from comment #31)
Actually cova and ghext should both get new hashes.

Comment on attachment 265601 [details]
games/xtxf

cova and ghext hashes are outdated

Comment 37 Rodrigo Osorio 2025-12-02 08:24:19 UTC

(In reply to charlesrocket from comment #36)

Good catch, thanks. This point was now solved.

Comment 38 Rodrigo Osorio 2025-12-03 10:40:45 UTC

Good news,

After polishing a little more, I was able to build both lang/zig and lang/zig014 and the height dependencies.
Next task, rearrange the commits and push it.

Comment 39 Rodrigo Osorio 2025-12-08 17:28:35 UTC

Hi,

This is the current state of lang/zig update:

 * I merged all the patches submitted in this PR by  Pat Maddox and Pero Oršolić
 * With some minor fixes I was able to build zig 14, 15 and the patched consumers

I also identify some missing ones:
 * ports-mgmt/zig2tuple, who uses the USES zig (and requires approval)
 * devel/zls

And i'm not absolutely sure about slowdive opinion's about the  games/xtxf

So to be completely transparent, and avoid frictions I pushed a code review with (my) final state https://reviews.freebsd.org/D54132

Feel free to comment and suggest improvements if required

(In reply to Rodrigo Osorio from comment #39)
xtxf is ready for 0.15.x, the last port revision here missed updated dependency hashes so it broke offline builds when the compiler tried to pull deps that were not defined in the port. zig2tuple has 0.15 branch and should be ready as well. Ill reach out to maybe get it released.

Comment 41 Rodrigo Osorio 2025-12-09 13:39:36 UTC

(In reply to charlesrocket from comment #40)

Yes I update the hashes and was able to compile it with zig>=0.15.1
If you are Ok with it, i'm ready to push the changes.

Regarding ports-mgmt/zig2tuple, there is no rush until the 0.15 branch become official

(In reply to Rodrigo Osorio from comment #41)
Yep it is a go from me

(In reply to Rodrigo Osorio from comment #41)
It's a go for me as well.

Also pushed the 0.15 commit to main branch.