Andrew Wilkins
2014-Oct-09 07:17 UTC
[LLVMdev] Proposal: bindings for the Go programming language
> 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.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". What benefit does combining the checkout into the "go get" bring, as opposed to deferring to update_llvm.sh as is done today? 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.> Comments appreciated.Thanks for taking this on. Cheers, Andrew [0] https://github.com/go-llvm/llvm/issues/25
Peter Collingbourne
2014-Oct-09 19:40 UTC
[LLVMdev] Proposal: bindings for the Go programming language
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 (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. > > 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 update_llvm.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
Andrew Wilkins
2014-Oct-10 07:16 UTC
[LLVMdev] Proposal: bindings for the Go programming language
On Thu, Oct 9, 2014 at 9:40 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:> 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 (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. >> >> 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 update_llvm.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.Fair enough. I made an invalid assumption that "go get" was going to transform the standard LLVM tree so it would come under the Go package directory.>> 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.Well that is a pain. I wasn't aware that pkg-config's format was so restrictive. I agree that packaging the bindings into distro packages is reasonably neat, my only concern is that it is not the usual practice of a lot of Go developers to use distro-provided Go packages. I'm not sure if any distros other than Debian/Ubuntu even have any. Ideally I'd like to avoid placing constraints on adoption of LLVM, but I think I'll have to concede that this approach is the best we can do right now without additional support from the "go" tool. Thanks, Andrew