You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our dependency tree today is a lot to maintain, and reducing its size would make performing Zig updates, contributing, etc. easier.
Despite how some feel ('zero dependencies!!!'), I do think dependencies are good when they are logical and not too small. I am happy with the size/quantity of some of our dependencies, but not others.
Possible improvements:
direct3d-headers is replaced by the newer directx-headers (better approach) - we just need to actually replace it.
mach-sysgpu currently depends on mach-gpu, it should not be needed.
mach-editor should not directly depend on mach-sysgpu, spirv-cross, or spirv-tools. The logic requiring these should be moved to e.g. mach-sysgpu, and mach-sysgpu should come from the mach dependency indirectly instead of via a direct dependency.
mach-examples should not directly depend on mach-freetype or zigimg.
mach-gpu and mach-gpu-dawn could be eliminated by fully embracing mach-sysgpu.
glfw and mach-glfw could be eliminated by moving all window-creation logic into mach-core directly, which we are doing for other platforms (web, android, etc. anyway)
vulkan-headers is only needed by mach-gpu-dawn and glfw, if both of those go away then it would no longer be needed.
The text was updated successfully, but these errors were encountered:
does this mean glfw and mach-glfw will be abandoned? or simply not one of mach-cores dependencies?
Unclear, no immediate plan here. We know a lot of people depend on and use mach-glfw. We also know that writing a Linux backend for mach-core would by far be the trickiest (GLFW does a superb job here.) We also know SDL provides some unique platforms which GLFW doesn't.
If mach-core first gets its own Windows and macOS backends, and somehow also gets a Linux backend which we feel can be competitive with GLFW in the numerous edge cases Linux has.. then GLFW wouldn't be part of mach-core dependencies anymore. If all that happened, and Mach itself doesn't use GLFW anymore, then at that point I think it would be worth considering what happens to mach-glfw after that. Until then, we stay the same course.
These TODOs are now captured by other filed issues: #1139, #1136
slimsag
changed the title
all: use a small flamethrower to burn branches of our dependency tree 🔥
all: use a large flamethrower to burn branches of our dependency tree 🔥
Feb 2, 2024
Our dependency tree today is a lot to maintain, and reducing its size would make performing Zig updates, contributing, etc. easier.
Despite how some feel ('zero dependencies!!!'), I do think dependencies are good when they are logical and not too small. I am happy with the size/quantity of some of our dependencies, but not others.
Possible improvements:
direct3d-headers
is replaced by the newerdirectx-headers
(better approach) - we just need to actually replace it.mach-sysgpu
currently depends onmach-gpu
, it should not be needed.mach-editor
should not directly depend onmach-sysgpu
,spirv-cross
, orspirv-tools
. The logic requiring these should be moved to e.g.mach-sysgpu
, andmach-sysgpu
should come from themach
dependency indirectly instead of via a direct dependency.mach-examples
should not directly depend onmach-freetype
orzigimg
.mach-gpu
andmach-gpu-dawn
could be eliminated by fully embracingmach-sysgpu
.glfw
andmach-glfw
could be eliminated by moving all window-creation logic intomach-core
directly, which we are doing for other platforms (web, android, etc. anyway)vulkan-headers
is only needed bymach-gpu-dawn
andglfw
, if both of those go away then it would no longer be needed.The text was updated successfully, but these errors were encountered: