Repository navigation
Stop bundling system dependencies - #36
nat3Github wants to merge 2 commits into
Conversation
Drops every dependency except SDL and all vendored headers except the generated Wayland protocols. Linux builds read headers from -Dinclude_path/-Dlibrary_path (defaulting to the host on native Linux builds), and xkbcommon/libdecor versions from the sysroot's pkg-config. macOS/Windows use SDL's bundled Khronos headers.
…fribidi, libthai Each disabled feature also drops the dev headers it needs from the sysroot. All default to true.
|
Thanks for the PR! My main motivation for this package is to make compiling and cross compiling SDL easy. Unless it is technically or legally not possible (eg macos), users should be able to simply “zig build” apps that depend on SDL for their desired target without additional configuration of their system. I’m closing this PR because it breaks this feature. However, I would accept other resolutions to #35. For example, we could try marking all platform specific dependencies as lazy, and also respect the zig flag (can’t remember the name at the moment but will edit this once I remind myself what it is) that requests to get the dependency from the system instead of fetching it. |
|
I think at this point our philosophies split. I have roughly 250 G of disk space on my computer. meaning maybe 20G for actual projects. cant afford decentralized build solutions with duplication... i'll check the lazy route, maybe this is comaptible with a buildroot and still lean |
|
I'm confident that it's possible for us to support both of these use cases in the same repo. Lazy dependencies may make this easy today, if they don't then IMO that's sufficient motivation to reconsider the design of lazy dependencies. |
agreed, but i think the issue is the ecosystem fragmentation / duplication, not lazy dependencies. a buildroot (i.e. linux debian root) would pretty much work with all zig packages, so i think it would be better to have repos for that or scripts for setting that up instead of build dep explosion - even if they are all lazy it's just a lot of effort compared to a centralized solution and its not only across dependencies but across the same build tree where duplication happens i just think that the simplification for crosscompilation is not worth it imo we shouldnt hide that from users - hack, on platforms like macos we legally cant. but on that point we probably disagree. |
|
I think it would be reasonable to create a repo that just contains the headers all in one place with unnecessary data removed, but I want to see how far we can push the decentralized solution first before falling back to that |
2 participants
see #35