[LLVMdev] Proposal: bindings for the Go programming language (original) (raw)

Peter Collingbourne peter at pcc.me.uk
Thu Oct 9 12:40:29 PDT 2014

On Thu, Oct 09, 2014 at 09:17:01AM +0200, Andrew Wilkins wrote:

> 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 (updatellvm.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.

Some users will want to build/install the bindings against existing LLVM libraries [0]. For example, if the vNN URL were used, then I think it would be nice to be able to fetch and build the bindings against a released vNN LLVM without also fetching the LLVM tree via "go get".

I think the best way to solve that problem is to rely on distro-specific packaging. For example, on Debian derived distributions we could arrange so you could add /usr/share/gocode to your $GOPATH and get the packaged version of LLVM that way.

But if we wanted to, we could support the scenario where the user manually checks out only the bindings, by letting people somehow run only the part of update_llvm.sh that generates llvm_config.go from a given llvm-config executable. I'd imagine this would be useful for distro packagers, as well.

What benefit does combining the checkout into the "go get" bring, as opposed to deferring to updatellvm.sh as is done today?

I think it is better to keep the management of the LLVM tree in $GOPATH in the hands of the developer as much as possible. In particular, I'm thinking of the scenario where someone does development on that copy of LLVM, and may want to check out arbitrary revisions, or use the LLVM git mirror (I can easily imagine doing this myself, for example). If we use separate checkouts for LLVM and the bindings, this becomes somewhat more cumbersome.

One option for improving the "go get" experience for released versions is to include pkg-config support in the OS distributions of LLVM. "go get" is able to invoke pkg-config to determine include/library paths, linker options, etc.

I think I did try generating a pkg-config file for LLVM at one point, but it wouldn't work with the "go" tool because the format only supports a "cflags" attribute, and we need the current separation between cppflags and cxxflags because the compiler did not accept the -std=c++11 flag in C mode.

Thanks,

Peter

More information about the llvm-dev mailing list