[llvm-dev] Future of Go bindings?

Ayke van Laethem via llvm-dev llvm-dev at lists.llvm.org
Sun May 3 09:06:19 PDT 2020


Hi all,

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
<https://github.com/tinygo-org/go-llvm> 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:

   1. Remove the Go bindings from the LLVM monorepo and continue
   development outside the project.
   2. 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.

Ayke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200503/990d0436/attachment.html>


More information about the llvm-dev mailing list