<div dir="ltr"><div><div>A quick browse through the contributors on <a href="https://github.com/go-llvm/llgo/graphs/contributors">https://github.com/go-llvm/llgo/graphs/contributors</a> 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?</div></div><div><br></div>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:<div><br></div><div>1. You can get the awesome code review of the LLVM community.</div><div>2. If people are changing the API, they have to fix in-tree stuff, so you are shielded from ongoing maintenance burden.</div><div><br></div><div>Since the code is in go, you don't really get 1; the community speaks C++.</div><div>IIRC the bindings are based on the C API, so they are stable and so 2 doesn't apply.</div><div><br></div><div>What are the advantages to having it checked in to the LLVM project?</div><div><br></div><div>-- Sean Silva</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 1:53 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'd like to propose the contribution of a Go frontend subproject to the LLVM<br>
project, based on the existing llgo project at <a href="https://github.com/go-llvm/llgo" target="_blank">https://github.com/go-llvm/llgo</a> .<br>
As with the previous contribution of the Go bindings, I have obtained<br>
permission from all llgo contributors whose code is part of this contribution,<br>
to contribute their changes to the LLVM project and relicense their changes<br>
under the LLVM license. I am also willing to be the code owner for the<br>
llgo subproject.<br>
<br>
The frontend would live in the LLVM svn repository and if checked out into<br>
tools/llgo would build as part of the regular LLVM build (with CMake only). We<br>
would be keeping llgo compatible with top-of-tree LLVM, although I imagine<br>
this would be less burdensome than the other subprojects as llgo is written<br>
in Go and depends on the Go bindings previously contributed to LLVM.<br>
<br>
llgo depends on certain third-party components, namely a copy of the Go<br>
standard library (libgo), a Go program analysis library (go.tools) and two<br>
library dependencies of the standard library (libbacktrace and libffi). These<br>
would be mirrored into the llgo repository under a third_party directory. They<br>
would retain their original licenses, which are BSD and GPLv3 with Runtime<br>
Library Exception (the latter only applies to a handful of header files;<br>
eventually we would seek to replace these).<br>
<br>
As a first step, I have published:<br>
<br>
<a href="http://reviews.llvm.org/D6327" target="_blank">http://reviews.llvm.org/D6327</a><br>
<br>
with the initial code contribution. The mirrored third-party sources will be<br>
added later, as the diff would be too large to review. If there is consensus<br>
in the community, the next step I propose to take is to create the subproject<br>
in svn and check in the initial version of the code.<br>
<br>
Any comments on this contribution are appreciated.<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Peter<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></span></blockquote></div><br></div>