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

[Andrew Wilkins]

On Thu, Nov 20, 2014 at 6:57 AM, Sean Silva <chisophugis at gmail.com> wrote:
> 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?

I am the original author of llgo, and FWIW I'm happy to work with the
LLVM infrastructure. Learning a new submission procedure isn't what's
going to hold me back, it's just lack of time right now.
Apart from Peter, there was really only one other who submitted a
significant amount of work, and he has not been involved for a fair
while now.

Cheers,
Andrew

> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Andrew Wilkins
http://awilkins.id.au