[LLVMdev] Proposal: add Go frontend subproject based on llgo

[Sean Silva]

A quick browse through the contributors on
https://github.com/go-llvm/llgo/graphs/contributors and some searches in my
mail suggests that none of the primary contributors are part of the LLVM
community. How are they going to continue developing llgo once it is the
LLVM repo?

Sorry if this is a dumb question, but what is the advantage of having this
in-tree as an LLVM project? I typically associate the following advantages
to having something in-tree:

1. You can get the awesome code review of the LLVM community.
2. If people are changing the API, they have to fix in-tree stuff, so you
are shielded from ongoing maintenance burden.

Since the code is in go, you don't really get 1; the community speaks C++.
IIRC the bindings are based on the C API, so they are stable and so 2
doesn't apply.

What are the advantages to having it checked in to the LLVM project?

-- Sean Silva


On Wed, Nov 19, 2014 at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> Hi all,
>
> I'd like to propose the contribution of a Go frontend subproject to the
> LLVM
> project, based on the existing llgo project at
> https://github.com/go-llvm/llgo .
> As with the previous contribution of the Go bindings, I have obtained
> permission from all llgo contributors whose code is part of this
> contribution,
> to contribute their changes to the LLVM project and relicense their changes
> under the LLVM license. I am also willing to be the code owner for the
> llgo subproject.
>
> The frontend would live in the LLVM svn repository and if checked out into
> tools/llgo would build as part of the regular LLVM build (with CMake
> only). We
> would be keeping llgo compatible with top-of-tree LLVM, although I imagine
> this would be less burdensome than the other subprojects as llgo is written
> in Go and depends on the Go bindings previously contributed to LLVM.
>
> llgo depends on certain third-party components, namely a copy of the Go
> standard library (libgo), a Go program analysis library (go.tools) and two
> library dependencies of the standard library (libbacktrace and libffi).
> These
> would be mirrored into the llgo repository under a third_party directory.
> They
> would retain their original licenses, which are BSD and GPLv3 with Runtime
> Library Exception (the latter only applies to a handful of header files;
> eventually we would seek to replace these).
>
> As a first step, I have published:
>
> http://reviews.llvm.org/D6327
>
> with the initial code contribution. The mirrored third-party sources will
> be
> added later, as the diff would be too large to review. If there is
> consensus
> in the community, the next step I propose to take is to create the
> subproject
> in svn and check in the initial version of the code.
>
> Any comments on this contribution are appreciated.
>
> Thanks,
> --
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/1e14225e/attachment.html>