bazel-central-registry
bazel-central-registry copied to clipboard
bazelbuild
wanted: rules_sdl2
Module location
https://github.com/JoyTeam/rules_sdl2
Link to bzlmod issue in the module's repository
https://github.com/JoyTeam/rules_sdl2/issues/1
Any other context to provide?
No response
Fund our work
- [ ] Sponsor our community's open source work by donating a feature bounty
Adding https://github.com/libsdl-org/SDL directly would probably be better. They don't want bazel files in the official repo (https://github.com/libsdl-org/SDL/issues/7769), but we can maintain patches that add them.
What would be the best way to synchronize our patches with the base commits in the official repo? I guess we'll need to maintain a fork, sync it time to time, and then somehow submit a tuple (commit in the original repo, diff file for that specific commit) to the registry. What are the mechanisms for that?
Another question: how mature the Bazel rules should be? Do they need to support all compilation modes (dynamic/static), all platforms (windows/macos/linux/android/ios), have all plugins configurable with conditional Bazel options (using select)? We don't need everything, so I can't promise to maintain everything.
The reason why I'm asking is that I forked a repo where somebody else started their Bazel configs that are not compatible with modules though, and they use a very old version of SDL. I started my own fork of the official repo (SDL 3 now) - https://github.com/libsdl-org/SDL/compare/main...JoyTeam:sdl:main, but it's less feature complete.
Please advise. I'm mostly interested in policies.
Maintaining a fork that generates a diff from the changes would work pretty well I think! Creating a bzlmod related branch that is based off the the release tag (such as this https://github.com/libsdl-org/SDL/tree/release-2.28.3). As for SDL3 - I don't think submitting to the BCR would be appropriate until they cut some kind of release.
how mature the Bazel rules should be?
Ideally all features would be supported, but incrementally supporting the most common features (or just the one you need!) would be a great start. Those who need more support would ideally contribute to add that support. New BCR submissions as support got better would probably be accepted via some incremental indicator 2.28.3.bcr.1 ... 2.28.3.bcr.2, etc.
BTW I'm the author of https://github.com/bazelregistry/sdl2 and if you want to collab on this effort, I'd be happy to! I don't need SDL as a bazel module right now, but I eventually would like to use it.
Ok, so I'll wait until SDL3 stabilizes and then come back. I'm going to use it anyway.
As we are porting our game to free software stack (special thanks to Unity) and going to build everything with Bazel, I will maintain a few other related libraries. So far I've made build rules for the following projects:
- https://github.com/JoyTeam/sdl
- https://github.com/JoyTeam/ogre
- https://github.com/JoyTeam/freetype
- https://github.com/JoyTeam/rmlui
I don't want to send PR to main repos, because Bazel rules are in a pretty early stage. Eventually when they work, I'll do it. Would it make sense to create entries in the Bazel registry with my repos and eventually switch it to the official ones when my patches are accepted?
If you're not sure it's appropriate to submit to the BCR you can create your own registry until you're ready! Here's a few examples:
- https://github.com/bazelboost/registry (I'm the maintainer)
- https://github.com/ecsact-dev/bazel_registry (I'm the maintainer)
- https://github.com/obazl/registry
Would it make sense to create entries in the Bazel registry with my repos and eventually switch it to the official ones when my patches are accepted?
I'm unsure about this, but I think @fmeum or @alexeagle or @meteorcloudy would be able to answer that better. The bazel slack (https://slack.bazel.build) might be a good place to get some answers as well.
One option might be to prefix your forks with @joyteam_*, for example @joyteam_ogre, and submit those.
Would it make sense to create entries in the Bazel registry with my repos and eventually switch it to the official ones when my patches are accepted?
I agree with @zaucy that, for complex projects, it might be a good idea to start with @joyteam_ogre and then have the modules graduate when the patches land upstream.
