Strip dvui dependencies to reduce diskspace and complexity, strip bundled proprietary sdks - #975
Draft
nat3Github wants to merge 20 commits into
Draft
nat3Github wants to merge 20 commits into
nat3Github wants to merge 20 commits into
Conversation
Both raylib backends were dragging in ~104M of duplicated Apple SDK headers (xcode_frameworks, license-questionable to redistribute) plus 70M of raylib's examples/ assets not needed to build the lib. Point .raylib and .raylib_zig at local path deps (../raylib-dev-fork, ../raylib-zig-dev-fork) that strip xcode_frameworks from linkMacOS and comment out examples/ from the fetched paths. raylib_zig's fork also points its own raylib/raygui deps at the same stripped forks instead of fetching separate copies. Verified via raylib-standalone, raylib-ontop, raylib-zig-standalone, raylib-zig-ontop -- all build and run cleanly.
Forked david-vanderson/tree-sitter (pinned c8cad6e) into ../lib-treesitter-dev-fork. Its own build.zig.zon .paths already scoped fetches to lib/src+lib/include, but the full clone still carried crates/, test/, docs/, binding_rust/, binding_web/, and 16 lazy wasmtime_c_api_* tarball deps that are unreachable (dvui never passes -Denable-wasm). Stripped those from the fork (6.2M -> 892K) and dropped the dead wasmtime deps from its zon. tree_sitter_json and tree_sitter_zig were audited too: tree_sitter_zig already declares a tight .paths upstream and its own nested tree-sitter dep is commented out in its build.zig (never fetched); tree_sitter_json has no build.zig.zon and is only 608K total, not worth forking. Verified via zig build check: same 4 pre-existing failures (pugl CoreVideo linking, wasm sbrk) occur identically with the original git-pinned tree_sitter, confirming this swap isn't the cause.
nat3Github
marked this pull request as draft
August 28, 2026 20:46
Both stripped-down SDL2/SDL3 forks' build.zig.zon .paths omitted several per-OS source directories (filesystem/unix, filesystem/windows, camera/pipewire, haptic/linux, misc/unix, timer/windows, etc.) that build.zig actually references for Linux/Windows targets, so zig fetch silently dropped them from the cached package and later builds failed with FileNotFound (SDL_camera_pipewire.c, SDL_sysfilesystem.c, ...). Fixed both forks by diffing every file referenced in build.zig's per-OS source lists against zig fetch --debug-hash's actual include list, added the missing directories, and repinned dvui's build.zig.zon to the new commits/hashes. Verified with a clean zig-pkg/.zig-cache: zig build -Dbackend=sdl2 and -Dbackend=sdl3 both build clean. Claude-Session: https://claude.ai/code/session_011kJHHt2H7dsEaNYvc2jeFR
nat3Github
marked this pull request as ready for review
August 28, 2026 21:55
Owner
|
I know I'm super behind on this, sorry! |
Collaborator
Author
|
dont stress, just wanted to bump, sorry for all those big PR's it's probably a lot of work maintaining this |
Owner
|
I like the intention here, but it seems like we should be working with upstream instead of forking them. Trying to keep the forks up to date would be very challenging. Some things like the pugl changes seem minor and easy to upstream. Also the wio thing, we should be able to upstream a change that checks For others, like the raygui, we might have to do more work, but raylib in general is friendly to zig and is likely to accept build.zig.zon patches. Can you push the sdl2 change? That's clear enough and sdl2 isn't changing anymore. Should nat3Github/lib-sdl3-dev-fork@c72375e just be upstreamed as a bugfix into sdl3? nat3Github/lib-sdl3-dev-fork@3aec7d3 seems like a bugfix to upstream to castholm? |
Collaborator
Author
generally agree. just slow and more work, but might be worth it. ill start open PR's
you mean pin the commit of my fork or open a PR on yours? |
Owner
Thank you. I realize it is a lot of work, so I can take it over if needed, just let me know.
Sorry, I mean pin your fork. I'll figure out what to do when zig 0.17 comes out. |
…ry, fix wio API adaptations - raylib fork rebuilt on real raysan5/raylib tag 6.0 history (not an orphan squash) with a minimal build.zig/build.zig.zon patch on top; hash now computed and pinned (5eba2ba9) - repin wio/raygui/raylib_zig/zglfw/tree_sitter/tree_sitter_json/pugl off their non-forked "-dev" repo URLs - adapt wio.zig to the new wio pin's clipboard API (callback-based instead of returning a value) and enableTextInput cursor field width (i16)
This was referenced Sep 4, 2026
… stray xcode_frameworks pull) main was still based on tag 6.0 and pulling xcode_frameworks (bundled Apple SDK headers) via that tag's build.zig.zon. Reapplied the same lean patch (sysroot-based linkMacOS, dropped examples step, forked raygui/emsdk/zemscripten deps, dropped CI workflows) directly onto upstream master (550dd0e3) instead, force-pushed to the fork's main, and repinned here.
zig-lib-sdl2-dev-fork had lost its GitHub fork relationship (fork:false, parent:null). Rebuilt on real history: forked david-vanderson/SDL (itself forked from andrewrk/SDL <- libsdl-org/SDL) to nat3Github/c-sdl2-dev, then cherry-picked the 4 zig-packaging commits that weren't upstream (zig 0.16 updates, lean-deps src enumeration) onto a c-sdl2-dev branch. Tree and package hash are byte-identical to the old pin; only the URL changed. Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
… build.zig.zon only) Squashed the earlier bundled patch (which also dropped the examples build step and repointed raygui/emsdk/zemscripten at forks) down to just what's required to stop bundling xcode_frameworks: linkMacOS switches to b.sysroot-based framework/include/lib paths, and the xcode_frameworks dependency entry is removed from build.zig.zon. CI workflow files stay deleted only because pushing them back requires an OAuth `workflow` scope this repo doesn't have — not a design choice. Verified with `zig build -Dbackend=raylib` against stock upstream raygui/emsdk/zemscripten.
c-sdl2-dev's c-sdl2-dev branch was based on a commit main has since
reverted ("zig 0.16 updates", later reverted as "Revert \"zig 0.16
updates\""). Rebased our 4 commits onto current main tip (c26038048),
resolving one real conflict in build.zig's emscripten include-dir
lookup in favor of the zig 0.16 std.Io.Dir API (dvui requires
minimum_zig_version 0.16.0), then squashed into a single commit.
Force-pushed; package hash unchanged.
Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
lib-sdl3-dev-fork had lost its GitHub fork relationship (fork:false, parent:null). Its ios-support branch's real upstream lineage turned out to be david-vanderson/SDL's `sdl3-smooth` branch (not `SDL3`, which is a plain unmodified mirror of libsdl-org/SDL with no zig build files) — confirmed by merge-base: sdl3-smooth's tip is the exact commit the 6 ios/lean-deps commits are built on. Forked david-vanderson/SDL to nat3Github/c-sdl3-dev and pushed those 6 commits on a c-sdl3-dev branch rooted in the fork's real sdl3-smooth history. Tree and package hash are byte-identical to the old pin; only the URL changed. Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
…w scope Regranted the gh token 'workflow' OAuth scope, which was blocking any push touching .github/workflows/* — even a byte-identical, unmodified push of upstream's tip failed with the same "refusing to allow an OAuth App..." error, confirming the workflow deletions in the previous commit were forced by that missing scope, not a real part of the patch. Re-did the same 2-line-summary patch (linkMacOS sysroot swap + drop xcode_frameworks dep) directly on top of unmodified upstream master, so main's diff against raysan5/raylib:master is now exactly build.zig + build.zig.zon.
…tale SDL3 branch The previous c-sdl3-dev repo turned out to actually be a copy of the SDL2 fork (renamed to c-sdl2-dev, with the sdl3 work stranded as a branch on it) — GitHub only allows one fork of a given upstream per account, so forking david-vanderson/SDL a second time silently reused the existing c-sdl2-dev fork instead of creating an independent repo. Rebuilt from scratch on castholm/SDL:release-3.4.x (the actively maintained SDL3-for-Zig package; david-vanderson/SDL:sdl3-smooth was just a stale mirror of it) since it isn't a GitHub-account fork target we already hold. Applied the 4 ios-support commits + the lean-deps src enumeration from lib-sdl3-dev-fork's ios-support branch as a single patch — it applied cleanly, and every file under castholm's 3.4.16 src/ tree (1142/1142) is covered by the enumerated .paths list. Pushed to a new nat3Github/c-lib-sdl3 repo. Verified sdl3gpu-standalone builds and runs against the new pin. Deleted the stray c-sdl3-dev branch off c-sdl2-dev. Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
Verified (and fixed) real macOS cross-compilation with --sysroot, which was previously untested and broken in two places: 1. Raylib fork's linkMacOS had addLibraryPath(sysroot/usr/lib), which double-joined with the sysroot Zig's own linker already applies via --sysroot forwarding (std.Build.Step.Compile:1599), producing a bogus doubled path and failing to open it. Dropped that call — framework path + include path are still explicit, but Zig's own -syslibroot handles usr/lib. Fixed on the fork (main now at 279a8e30) and repinned here. 2. dvui's own raylib-c.h translate-c step and backend module had zero macOS SDK path wiring, unlike the SDL3 backend which already has this via resolveMacosSdkPath() + sdl3_system_*_path overrides. raylib-c.h pulls in GLFW/glfw3.h, which includes <OpenGL/gl.h> on macOS — a framework header translate-c can't find without an explicit -F path. Added the same auto-detect-or-override wiring used by SDL3, reusing the existing sdl3_system_include_path/sdl3_system_framework_path options (they're already backed by generic -Dsystem_include_path/-Dsystem_framework_path flags, not actually SDL3-specific). Verified both `zig build -Dbackend=raylib` (native) and `zig build -Dbackend=raylib -Dtarget=aarch64-macos --sysroot "$(xcrun --show-sdk-path)"` (cross-compile) succeed, using isolated ZIG_GLOBAL_CACHE_DIR dirs to rule out this session's own cache pollution.
Same root cause as the raylib fix (commit 7bbf42c): a dependency fork's own build.zig can add framework/include/library search paths to its own module, but those don't propagate to a *different* module that links against it (a translate-c step, or dvui's own backend wrapper module). Each such module needs the paths explicitly. Fork-side fixes (drop the double-joined addLibraryPath(sysroot/usr/lib), add explicit -F/-I where missing): - c-sdl2-dev branch c-sdl2-dev: SDL library's own macOS block - zig-lib-wio-dev branch lean-deps-macos-sysroot: wio module's macOS block - zig-lib-zglfw-dev: already fixed upstream (commit 9dac2da), repinned - zig-lib-pugl-dev: pugl module's macOS block dvui-side fixes (new addMacosSdkSearchPaths helper, reusing the sdl3_system_include_path/framework_path/library_path options since they're generic, not actually SDL3-specific): - sdl2: SDL2_config lib (config.mm needs Foundation.h) and sdl_mod itself - glfw: glfw_mod, plus an explicit /usr/lib library path for -lobjc (Zig rejoins a cwd_relative library path onto --sysroot itself, so passing plain "/usr/lib" avoids double-joining) - wio: wio_backend_mod - pugl: pugl_backend_mod examples/glfw-opengl-ontop.zig and src/backends/glfw.zig pick up an extra null parameter on zglfw's Window.create from the repin. Verified locally: native builds and aarch64-macos --sysroot cross-compiles for sdl2/glfw/wio/pugl/raylib, using a real Xcode SDK as the sysroot and isolated ZIG_GLOBAL_CACHE_DIR dirs per build. Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
…work paths, stale nested pin) Three independent breaks in the compile-macos-cross matrix (and, for sdl3/sdl3gpu, the plain native compile job too): - sdl3: nat3Github/c-lib-sdl3 (created in e62175b) had its name recycled by a later rename of the SDL2 fork, so the pinned commit resolved to nothing ("unable to create fetch stream: EndOfStream"). Recovered the exact content from the local zig package cache (content hash unchanged) and pushed it as a c-lib-sdl3 branch on c-lib-sdl-dev, the fork's current name, per the user: that repo now hosts sdl2/sdl3 as separate branches instead of separate repos. - sdl3gpu: unlike the sdl3 backend, sdl3gpu's own module never got the macOS framework/include search paths (addMacosSdkSearchPaths was never called for it) -- same class of bug fixed for sdl2/glfw/wio/pugl in 684d7b9, just missed for this backend. - raylib_zig: two stacked bugs in the zig-lib-raylib-zig-dev fork. (1) build.zig unconditionally did raylib_headers.get("raygui.h").? at configure time (not deferred to the "binding" step), crashing with "attempt to use null value" whenever raygui's own lazyDependency hadn't resolved yet -- guarded it to skip instead of panic. (2) its build.zig.zon pinned an older raylib commit than dvui's own pin, predating the --sysroot doubled-usr/lib fix from 7bbf42c -- repinned to match. Also needed the same addMacosSdkSearchPaths call as sdl3gpu for its own backend module. Verified locally: native builds and aarch64-macos --sysroot cross-compiles for all 8 compile-macos-cross backends (sdl2/sdl3/sdl3gpu/raylib/ raylib_zig/glfw/wio/pugl), using a real Xcode SDK as the sysroot and isolated ZIG_GLOBAL_CACHE_DIR dirs per build. Claude-Session: https://claude.ai/code/session_014h4Pvv5as2wHD7mzovYsrz
…/zglfw/pugl/zgl backends, re-pin forks
nat3Github
marked this pull request as draft
September 6, 2026 08:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
tldr: our deps bundle a lot of stuff not actually needed for compilation, we also bundle apple sdks which is a legal risk.
closes #926
TODO(future):
think about how we (dvui main) keep our dependencies lean.
add documentation table for cross compilation that exactly documents system sdk build dependencies across backends and configurations and a Help Section how to set up sysroot for cross compilation