[LLVMdev] Proposal: bindings for the Go programming language

[Peter Collingbourne]

Hi all,

I'd like to propose that we add an official set of Go bindings to the LLVM
project. These bindings are based on the existing "gollvm" project [1]. (Note
that all contributors to the gollvm project have agreed to relicense their
changes under the LLVM license and submit them to the LLVM project.) The
bindings would live in the LLVM tree under the bindings/go directory.

One thing that I'd like to see come out of this is the contribution of an
official Go frontend to the project, based on the existing llgo project [2]
which uses these bindings.

I am also submitting a patch with the initial version of the code to
llvm-commits.

For those familiar with Go, here are a few more details to explain how
clients would use the bindings and how they would be integrated with LLVM.

Clients would use a package import path that looks like this:

llvm.org/llvm/bindings/go/llvm

or for releases:

llvm.org/llvm.v36/bindings/go/llvm

Importing this path would cause 'go get' to check out LLVM plus the bindings
from SVN using the mechanism described in [3]. We would check index.html
files into the www repository to support this.

There doesn't seem to be a good way to build complex C++ projects such as LLVM
using 'go get', so there is a script (update_llvm.sh) that builds LLVM and
configures the package tree with the appropriate compiler/linker flags. This
is essentially the approach that I've taken with the existing gollvm project,
but now the script uses the copy of LLVM in the parent directory instead of
checking one out.

There is also a mechanism (independent of how Go users would use the
package with 'go get') to test that the bindings build and pass their test
suite. This would be done as part of the 'check' target if the user has Go
installed. The intention is that there would be at least one build bot set
up with Go installed to notify us when the bindings break.

Because there isn't normally a separate build step for Go libraries (a Go
library is normally built as a side effect of building an executable that
uses it), the bindings would not be built as part of the 'all' target, as this
would slow down the build and be redundant with work done later by 'check'.

Comments appreciated.

Thanks,
-- 
Peter

[1] https://github.com/go-llvm/llvm
[2] https://github.com/go-llvm/llgo
[3] https://golang.org/cmd/go/#hdr-Remote_import_paths