Check if the variable GO_IMPORT is
set in the recipe. If not generate an error.
Test building go-helloworld when GO_IMPORT assigned
Test building go-helloworld when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test building any other recipe(e.g bash) when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test creating a GO recipe with recipetool (not affected)
Test selftest test_recipetool_create_go (not affected)
Test selftest test_recipetool_create_go_replace_modules (not affected)
[YOCTO #15763]
CC: Yoann Congal <yoann.congal@smile.fr>
CC: Randy MacLeod <randy.macleod@windriver.com>
(From OE-Core rev: 374a91204bdaf44067f6b0ae89ed60934751efaa)
Signed-off-by: Christos Gavros <gavrosc@yahoo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After upstream go applied commit [cmd: remove support for
GOROOT_FINAL][1], GOROOT_FINAL variable is dropped and use
option -trimpath to instead [2]
The option -trimpath has already been added to GOBUILDFLAGS
in go.bbclass
[1] 507d1b22f4
[2] https://github.com/golang/go/issues/62047
(From OE-Core rev: 791ab77ac05f658ecd61525a3d9b1afaf8ac6e06)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The go class has its own fork of the base unpack code. At the time I was
told this was fine, it now isn't as that code is changing.
Rather than have a fork, put the path magic into a variable and then go
recipes can just set SRC_URI appropriately, e.g.:
git://go.googlesource.com/example;branch=master;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}
This avoids having special case hacks in the class and makes everything
a little more obvious.
(From OE-Core rev: cc4ec43a2b657fb4c58429ab14f1edc2473c1327)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will make possible to restore the default dynamic linking globally
which is what we had before the 1.20.X release.
(From OE-Core rev: 6ad90fc2fc49c4199a59dfb1c1d81a7ba184a522)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The GOPROXY is already correctly defined on the native sys root
and this can be checked using the bitbake devshell:
| $ go env GOPROXY
| https://proxy.golang.org,direct
The go_do_compile task calls the compiler directly so the
GOPROXY env is not seen because it's not defined in the shell.
Defining it explicitly solves this problem and was to avoid
setting it in the recipes itself.
(From OE-Core rev: e0919a3f7bc26b1ea9fb57740de4a9a3b9253f26)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is little point in having "crosssdk" suffex added to the virtual provider within
gcc/go since the TARGET_PREFIX or SDK_PREFIX already encapsulates this. Remove it
allowing some of the special case overriding to be removed.
This also allows removal of some of the MLPREFIX usage since again, the triplet
also covers this.
(From OE-Core rev: fe0206ba482d209b24e636d578aa68ba5e67ba1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
