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
We're going to move standalone libraries out of the monorepo libs/ directory.
What this means:
libs/glfw for example will canonically live at a repository like https://github.com/hexops/mach-glfw, with PRs being accepted there, as it will no longer live in the monorepo.
The main Mach repository will depend on those standalone repos using the new Zig package manager.
We will still maintain just one issue tracker (in the main hexops/mach repository)
We will leverage Wrench (our automation bot) more to make cross-repository changes, like updating the version of Zig we use across all repos, standardizing CI pipelines, etc.
Most of the Mach Engine codebase will still live in the main monorepo, specifically the "standard library" of optional ECS modules we will soon provide.
Why?
Right now it is easy to get confused by the structure of the Mach codebase, and think that libs/ are more tied together than they actually are. I'd like to make it even more clear that libs/ are 100% standalone Zig libraries, remove cruft from READMEs that explains the monorepo situation.
It's taken longer than I thought to explain the monorepo setup to people who are talented Zig engineers, and I've seen people like Andrew think e.g. libs/glfw living in this repository means that it's not community maintained or such. It'd be nice to put that to rest and just make it a standalone GitHub repository that matches people's default assumptions.
The Zig package manager doesn't support monorepos well right now since it is so early-stages, adopting this would let us use it sooner. This is a nice-to-have, not strictly required. Andrew has said Zig will support our monorepo use case eventually.
How?
I will make this change one-by-one so that we maintain the commit history of such projects.
Once this change goes through, we generally cannot ever undo this. The way that dev/push-subrepos.sh works effectively requires that it be one-way, and as soon as we allow PRs in e.g. github.com/hexops/mach-glfw we cannot ever go back.
We're going to move standalone libraries out of the monorepo
libs/
directory.What this means:
libs/glfw
for example will canonically live at a repository like https://github.com/hexops/mach-glfw, with PRs being accepted there, as it will no longer live in the monorepo.Why?
libs/
are more tied together than they actually are. I'd like to make it even more clear thatlibs/
are 100% standalone Zig libraries, remove cruft from READMEs that explains the monorepo situation.libs/glfw
living in this repository means that it's not community maintained or such. It'd be nice to put that to rest and just make it a standalone GitHub repository that matches people's default assumptions.How?
I will make this change one-by-one so that we maintain the commit history of such projects.
Once this change goes through, we generally cannot ever undo this. The way that
dev/push-subrepos.sh
works effectively requires that it be one-way, and as soon as we allow PRs in e.g. github.com/hexops/mach-glfw we cannot ever go back.Status
The following projects have been migrated:
The text was updated successfully, but these errors were encountered: