[yocto] Integrating Golang

[Ilya Dmitrichenko]

Hi Leo and Martin,

On 17 April 2014 20:54, Leo Schwab <lschwab at sensity.com> wrote:
> On Thu, Apr 17, 2014 at 1:49 AM, Martin Donnelly <martin.donnelly at ge.com> wrote:
>> On 05/03/2014 21:55, Leo Schwab wrote:
>>> Has anyone else done any work here?  Is there anything that I can
>>> steal^H^H^H^H^Htake inspiration from?  Or am I in completely
>>> unexplored territory?
>>
>> I posted an RFC patch set last year but it didn't get any traction and
>> we subsequently ruled out use of go so I never followed up on it but it
>> might be a useful starting point.
>>
>> http://lists.openembedded.org/pipermail/openembedded-core/2013-May/078606.html
>>
> We cobbled together our own recipes to build the Go compiler
> (available upon request), which seem to be working well enough.  We
> didn't need to make any changes to the recipes building the GCC
> toolchain.

I would be very much interested to take a look at what you did. My
use-case right now is to build Docker with Yocto.

Are using gogcc? From what understood it doen't build static binary
like gc does... which is, to be honest, my favourite feature of Go.

> What I was more interested in learning was how people were integrating
> the building of Go applications into Yocto.  Specifically: 'go get
> foo' will build 'foo' and, in the process, fetch and build all its
> dependencies.  This conflicts directly with Yocto's duties -- fetching
> and building dependencies.

I understand your concern with `go get` fetching dependencies that
bitbake should rather fetch. However, I would rather avoid using
global $GOPATH and set it to be relative to the build directory, i.e.
have per-project $GOPATH. That way `go get` is just a step in the
build process and doesn't intervine with bitbake in any way.

I have previously written a few recipes for some Python packages, and
do know that Yocto doesn't use any of the convinient tools (i.e.
easy_install or pip), but I would debate that it should and, perhaps,
in combination with virtualenv as well. There is currently no support
for Python 3 in Yocto, which is something that needs looking into and
I would also look into using pip then also.

> My current not-solution is rather ugly:  Create a repository that is a
> standard Go build environment pre-populated with the app source code
> and all of its dependencies.  The idea is that 'go get foo' will find
> everything it needs already there and won't try and fetch anything
> else.  Then create a simple Yocto recipe that fetches this repository
> and builds it using 'go get ...'.  The repository itself is maintained
> via rather delicate use of git-subtree.
> This gets the job done, and prevents Go and Yocto having a fight about
> who fetches what and how, but it's damned ugly...

This is kind of an okay solution, as Go community is not interested to
have `go get` to handle versions of dependcy, which is somewhat fair.
So if you needs to pin specific revisions, you will have to do either
subtree or submodule or script that just clones those deps or or
anything else of this kind.

I don't think it's any useful if you have to write bitbake recipe for
each little Go library you might be using, this is not C and `go get`
just works for most part. And when it doesn't, I would either fork and
import from my own fork or checkout a working revision of give
dependency and do git add on it, checking it into my project's main
tree.

I think at this stage it's improtant to provide a working Go compiler
for the Yocto community to use on their own projects. There are
currently only very few things that one might treat as system-level
tools, well, I can only recall of one actually, and it's the one I'm
attempting to integrate - Docker.

Cheers,
-- 
Ilya