openembedded-core.git/meta/recipes-devtools/go, branch master-next2

recipes/*-cross recipes: ignore TARGET_ARCH sstate hash

2017-04-12T14:02:13+00:00

"yocto-compat-layer.py --machines" showed that shared packages like
gcc-cross-powerpc64 have a sstate signature that depends on
TUNEFLAGS. As a result, there are unnecessary rebuilds and potential
conflicts in a multiconfig.

That's due to the way how TARGET_ARCH is set. Richard Purdie suggested
setting TARGET_ARCH[vardepvalue] as fix, which works. It would be
shorter to do that in cross.bbclass instead of repeating the relevant
line in different recipes, but Richard was concerned about potential
side-effects in other usages of cross.bbclass.

TARGET_GOARM as used in go.inc is still causing signature differences
for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This
needs further investigation.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

go-cross: avoid libgcc dependency

2017-04-12T14:02:13+00:00

libgcc gets compiled differently depending on the tune flags for the
target. That dependency would make go-cross also tune specific and
prevent sharing it between different machines using the same
architecture.

For example, MACHINE=intel-corei7-64 and MACHINE=qemux86-64 shared the
same go-cross-x86_64, but compiled libgcc differently.

The libgcc dependency gets inherited from go.inc, but does not seem to
be necessary for go-cross (compiling go-helloworld still succeeds).
The dependency is left in go.inc conditionally, just in case that it
really is relevant for the various on-target recipes which inherit
that.

Because go-cross*.bb includes go*.bb, moving the DEPENDS into a .inc
file that only gets included for the target recipes doesn't
work. Reshuffling the content of three .bb files seems too intrusive
at this point.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

go-native: Install bootstrap binaries with 1.4 suffix

2017-03-21T22:43:04+00:00

Currently, bin/go and bin/gofmt collide between go-native
and go-bootstrap-native packages, these are scripts anyway
which call the go compiler proper from right install, in
this case create go1.4 and gofmt1.4 names for these scripts
to avoid namespace collision

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton

go: Remove mips32r2 from mips

2017-03-17T15:37:05+00:00

mips32r1 is only one supported for mips32

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

go: Fix packaging for target go

2017-03-17T15:37:04+00:00

We need all packaging tasks when building
go for target

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

go: add native recipes for 1.8

2017-03-14T14:39:04+00:00

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

go: Enable on musl

2017-03-14T14:39:04+00:00

Working fine for musl targets now

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

go: Add recipes for golang compilers and tools

2017-03-10T14:50:16+00:00

* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

* Disable for musl, at least for now

* Disable for x32/ppc32 which is not supported

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie