At the moment the Go bindings to LLVM (which are mostly based on the C bindings) appear to be largely unmaintained.
At the same time, the main user of these bindings within the LLVM repository (llgo) has been removed a few months ago, so there isn’t a real need for the bindings to stay within the LLVM project. However for a project I’m working on (TinyGo) I heavily depend on these bindings. In fact, for ease of development and because I didn’t want to wait for patches to be merged to use them, I’ve forked the LLVM bindings while pulling in upstream changes and sending most local changes upstream.
I don’t think the current situation is maintainable and would propose two possible ways forward:
- Remove the Go bindings from the LLVM monorepo and continue development outside the project.
- Continue development within the LLVM monorepo. In which case someone would need to be prepared to review the occasional Go (and C) binding patch.
I’m not sure what the usual process is for getting code maintainership and what the exact requirements for that are. However, if the bindings are kept I would be willing to take over maintainership of the Go and C bindings. Please note however that I am still relatively new to the LLVM project and I can’t follow everything that is going on (at the moment, LLVM weekly is my main source of LLVM news). And if the Go bindings are removed that still leaves the question of who will maintain the C bindings.
So my question is now: what would be the best way forward for the Go bindings and who will take ownership of the (remaining) bindings?
For me, I would be fine with maintaining them outside the LLVM project, but perhaps there are reasons to keep them in-tree.