Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: use a large flamethrower to burn branches of our dependency tree 馃敟 #1136

Closed
1 of 7 tasks
slimsag opened this issue Jan 7, 2024 · 3 comments
Closed
1 of 7 tasks
Labels
Milestone

Comments

@slimsag
Copy link
Member

slimsag commented Jan 7, 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.

image

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.
@slimsag slimsag added the all label Jan 7, 2024
@slimsag slimsag added this to the Mach 0.4 milestone Jan 7, 2024
@xdBronch
Copy link
Contributor

xdBronch commented Jan 7, 2024

does this mean glfw and mach-glfw will be abandoned? or simply not one of mach-cores dependencies?

@slimsag
Copy link
Member Author

slimsag commented Jan 7, 2024

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.

slimsag added a commit that referenced this issue Jan 7, 2024
These TODOs are now captured by other filed issues: #1139, #1136
@slimsag 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
@slimsag
Copy link
Member Author

slimsag commented Mar 6, 2024

Broken out into:

#1166

#1165

#1174

#1173

#1172

@slimsag slimsag closed this as completed Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants