Windows build fails on Zig 0.17.0-dev.667+0569f1f6a due to unused config header values

[kenjpirkle]

Summary

On Windows, building this package with newer Zig master fails during SDL_build_config.h generation because the Windows config helper provides several values that are not present in upstream SDL 3.4.4's SDL_build_config.h.cmake.

This appears to be exposed by newer Zig versions being stricter about unused addConfigHeader values.

Platform

Windows x86_64

Zig versions tested

Works:

0.16.0
0.17.0-dev.101+4e2147d14

Fails:

0.17.0-dev.667+0569f1f6a
0.17.0-dev.263+0add2dfc4

Error

            └─ compile lib SDL3 Debug native
               └─ configure cmake header dependency to SDL_build_config.h failure
error: C:\Repositories\sdl-build-failure-test\zig-pkg\N-V-__8AAL9L9AJxY67Fhxp52_VHlLps195MF3irmi4z8Qge\include/build_config/SDL_build_config.h.cmake: config header value unused: HAVE_D3D11_H
error: C:\Repositories\sdl-build-failure-test\zig-pkg\N-V-__8AAL9L9AJxY67Fhxp52_VHlLps195MF3irmi4z8Qge\include/build_config/SDL_build_config.h.cmake: config header value unused: HAVE_AUDIOCLIENT_H
error: C:\Repositories\sdl-build-failure-test\zig-pkg\N-V-__8AAL9L9AJxY67Fhxp52_VHlLps195MF3irmi4z8Qge\include/build_config/SDL_build_config.h.cmake: config header value unused: HAVE_SENSORSAPI_H

The Windows config code in this package appears to provide them to b.addConfigHeader, and removing the three entries locally allows the build to get past config-header generation:

.HAVE_D3D11_H = true,
.HAVE_AUDIOCLIENT_H = true,
.HAVE_SENSORSAPI_H = true,

Expected behaviour

The package should build without unused config-header values when used with newer Zig versions.

Question

Are these three HAVE_* values stale for SDL 3.4.4 and safe to remove, or should they be replaced with newer SDL config names?

Additional context

After removing those entries, build still fails later in translate-c, involving missing builtins (44 missing in total) such as:

__builtin_elementwise_fshr
__builtin_elementwise_fshl

I'm almost certain these are due to the upgrade to LLVM 22 or translate-c/arocc related (a couple of issues regarding missing builtins exist and/or have been fixed in translate-c)

[MasonRemaley]

Thanks for the report! I’ll make sure this is resolved before Zig 0.17 is tagged. I believe the translate C issue has been resolved upstream but this version isn’t yet pulled in by master branch zig, but will double check.

[kenjpirkle]

Much appreciated, thank you!

I had a quick look and it seems to be down to these changes: https://codeberg.org/ziglang/zig/commit/9989f72c61e4c4e98c69f6191a63c201336a6a19#diff-d4e3d13ed5f02fd67c14d0f0289ace71c5faec31 (ensureAllValuesUsed) - the previous version was checking unused autoconf and nasm values, but not cmake values, letting the build succeed.

(P.S. Loved the talks you gave!)

[MasonRemaley]

No prob! I was about to get blocked by this too.

I had a quick look and it seems to be down to these changes: https://codeberg.org/ziglang/zig/commit/9989f72c61e4c4e98c69f6191a63c201336a6a19#diff-d4e3d13ed5f02fd67c14d0f0289ace71c5faec31 (ensureAllValuesUsed) - the previous version was checking unused autoconf and nasm values, but not cmake values, letting the build succeed.

That makes sense, I also noticed this in 43f8a9c but failed to fix the Windows defines there because I didn't scroll past the translate C errors.

(P.S. Loved the talks you gave!)

Thanks!! :)

[MasonRemaley]

I don't have a mac to test on, but I just kicked off a CI run to see if macOS has a similar issue WRT the build header defines.

I'm also building latest Zig locally right now, if building SDL for Windows still fails due to the vector conversions I'll check with latest translate C to verify that it's been resolved & make sure that fix gets in for the tag.

[EDIT] macOS passed CI

[MasonRemaley]

The vector conversion issue was solved by updating to the latest translate C by depending on the translate C package instead of the translate C step, this is how translate C will work in the future anyway. The package has some fixes that didn't make it into the in-repo version yet.

The fix is in #23, I'm waiting to merge it until Zig 0.17.0 is tagged since it breaks compat with Zig 0.16.0, but you're welcome to depend on that branch instead of master if you're targeting latest Zig. That's what I'll be doing.