x/mobile: build failing when using go modules

Question

x/mobile: build failing when using go modules

mirza-s opened this issue 7 years ago · 77 comments

mirza-s commented 7 years ago

What version of Go are you using (`go version`)?

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN="/Users/mbp/go/bin"
GOCACHE="/Users/mbp/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mbp/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mbp/wrk/src/libfp/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nt/0hzfppd92jvbk99fhvnhy8ph0000gn/T/go-build526348344=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

gomobile bind -target=android .

What did you expect to see?

Normal build as when building inside GOPATH

What did you see instead?

gomobile: go build -buildmode=c-shared -o=/var/folders/nt/0hzfppd92jvbk99fhvnhy8ph0000gn/T/gomobile-work-327189385/android/src/main/jniLibs/armeabi-v7a/libgojni.so gobind failed: exit status 1
go: finding github.com/dustin/go-humanize v0.0.0-20180713052910-9f541cc9db5d
go: finding golang.org/x/mobile v0.0.0-20180808221059-bceb7ef27cc6
can't load package: package gobind: unknown import path "gobind": cannot find module providing package gobind

Answer 1 · 2018-09-10T03:38:25.000Z

Hi, what's going on this?

Answer 2 · 2018-09-19T00:31:38.000Z

I have the same issue but with some different error message:

gomobile: /home/wangyun/dev/gopath/bin/gobind -lang=go,java -outdir=/tmp/gomobile-work-948078978 testaar failed: exit status 1
unable to import bind: cannot find package "golang.org/x/mobile/bind" in any of:
/home/wangyun/dev/software/go/src/golang.org/x/mobile/bind (from $GOROOT)
/home/wangyun/dev/gopath/src/golang.org/x/mobile/bind (from $GOPATH)
unable to import bind: cannot find package "golang.org/x/mobile/bind" in any of:
/home/wangyun/dev/software/go/src/golang.org/x/mobile/bind (from $GOROOT)
/home/wangyun/dev/gopath/src/golang.org/x/mobile/bind (from $GOPATH)
unable to import bind/java: cannot find package "golang.org/x/mobile/bind/java" in any of:
/home/wangyun/dev/software/go/src/golang.org/x/mobile/bind/java (from $GOROOT)
/home/wangyun/dev/gopath/src/golang.org/x/mobile/bind/java (from $GOPATH)

I'm using go 1.11 and updated gomobile, gobind to the latest version.

Answer 3 · 2018-10-10T03:24:43.000Z

'''
env go111module=off gomobile bind
'''
it's will temporarily worked fine

Answer 4 · 2018-11-14T05:24:07.000Z

cc @eliasnaur - some time has elapsed since this issue and I'm not sufficiently up to speed to know whether mobile is now modules-aware.

Answer 5 · 2018-11-14T08:23:45.000Z

Gomobile has not been converted. ons. 14. nov. 2018 06.25 skrev Paul Jolly <notifications@github.com>:

…

cc @eliasnaur <https://github.com/eliasnaur> - some time has elapsed since this issue and I'm not sufficiently up to speed to know whether mobile is now modules-aware. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27234 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgCDBmUNHJxqpeDT1Njw9kvu-CzgzI3ks5uu6lJgaJpZM4WMvnl> .

Answer 6 · 2018-11-28T12:24:09.000Z

is there work currently being done on this front?

Answer 7 · 2018-11-28T12:45:01.000Z

Not yet, at least not from my side. Partly because of time available, partly because I prefer to wait for module support to mature (GO111MODULE always on, the go/packages package feature complete and so on), but the main stumbling block is that I can't see the gomobile bind mode work as usual in module mode, at least not in its current form.
The problem is vendoring: gomobile bind generates a main package that in turn imports the packages you want to export to Java or Objective C. That works well in GOPATH mode, but not in module mode. Suppose gomobile bind in module mode generates a module containing a main package and your module as a dependency. Then, because vendored packages are only respected for the main module, any vendored packages from your module will be ignored by the go tool.
Perhaps some form of #26640 will help gomobile. Perhaps gomobile bind should work in a different way. I haven't thought that much about it.

Answer 8 · 2018-11-28T12:54:36.000Z

I started a conversation about gomobile and modules here: https://groups.google.com/forum/#!topic/golang-dev/C0ip7pFC2Oc

One question I would like you to ponder on that thread is whether it would be acceptable to require gomobile users to first generate glue code with the gobind tool and then only let the gomobile tool do the final packaging.

Answer 9 · 2019-03-12T16:51:59.000Z

Change https://golang.org/cl/167180 mentions this issue: all: add go.mod

Answer 10 · 2019-03-12T16:52:00.000Z

Change https://golang.org/cl/167179 mentions this issue: all: set GO111MODULE=off explicitly in bind tests

Answer 11 · 2019-03-16T14:59:07.000Z

Change https://golang.org/cl/167659 mentions this issue: cmd/gomobile: explicitly disable modules

Answer 12 · 2019-03-17T09:07:23.000Z

Hi, I use modules heavily in my projects. Unfortunately, this makes using gomobile rather difficult. When do you expect gomobile to support modules? Any updates on this?

Answer 13 · 2019-03-17T09:27:34.000Z

I was wondering whether packages that use major versions like /v2 are available with go mobile or not.

Answer 14 · 2019-04-17T10:27:56.000Z

We also need this feature desperately!

Answer 15 · 2019-04-18T00:14:23.000Z

Are there any workarounds for the meantime?

Answer 16 · 2019-04-18T06:37:17.000Z

@balupton / @chrisprobst: I use go mod vendor then switch GO111MODULE=off and build it as a regular vendored project.

Answer 17 · 2019-05-07T11:32:34.000Z

@balupton / @chrisprobst: We basically also use go mod vendor. However I've created a small tool (GoUp) which automates this process for us.

Answer 18 · 2019-06-10T11:42:21.000Z

Change https://golang.org/cl/181158 mentions this issue: cmd/gomobile: don't bind when not in gopath

Answer 19 · 2019-07-02T12:06:24.000Z

I have problem, which probably related with it - MoonSHRD/p2chat-android#2. Please, help me, if someone already solved this problem...

Answer 20 · 2019-08-05T13:27:10.000Z

CC @hyangah

As we discussed on emails, I decided to tackle this issue :)

My current understanding is that there are three action items roughly:

Fix gobind to work with Go modules
Fix gomobile-bind to work with Go modules
Fix gomobile-build to work with Go modules

The item 1. and 3. seem straight forward. 2. might be more complicated. As Hana said to me, "That conflicts with the assumption of the module-based build system and requires redesign.". Let's discuss about 2. later.

I'm now working on 1., but I found a problem. The reverse binding like "Java/" or "ObjC/" doesn't work with GO111MODULE=on: The below is one of the result. TestGobind/Java-Javapkg-WithModule is the same test as TestGobind/Java-Javapkg, but with GO111MODULE on.

    --- FAIL: TestGobind/Java-Javapkg-WithModule (9.37s)
            gobind_test.go:91: gobind -lang java golang.org/x/mobile/bind/testdata/testpkg/javapkg failed: exit status 1: type-checking package "golang.org/x/mobile/bind/testdata/testpkg/javapkg" failed (/Users/hajimehoshi/mobile/bind/testdata/testpkg/javapkg/classes.go:8:2: could not import Java/java/beans (go/build: importGo Java/java/beans: exit status 1
                        can't load package: package Java/java/beans: unknown import path "Java/java/beans": cannot find module providing package Java/java/beans

            ))

I was wondering if reverse binding is still (actively) supported or not. As far as I remember, the example using reverse binding was deleted due to unsolvable circular dependencies: https://go.googlesource.com/mobile/+/2f2872eacd7fc12c252096592f87e9b23bd5be8b If we need to keep the reverse binding, I'll do so. My concern is that reverse binding does not match with the notion of modules. If we can remove the reverse binding, I'd want to remove the reverse binding first. I tend to want to remove it, but I am not sure it'd be fine.

Any opinions?

Answer 21 · 2019-08-05T14:38:50.000Z

As we discussed on emails, I decided to tackle this issue :)

Thank you!

I was wondering if reverse binding is still (actively) supported or not.

I think the level of support is the same for reverse bindings as for the regular bindings. Reverse bindings are less mature however and have probably seen less use.

As far as I remember, the example using reverse binding was deleted due to unsolvable circular dependencies: https://go.googlesource.com/mobile/+/2f2872eacd7fc12c252096592f87e9b23bd5be8b

Note that circular references are a problem for both regular and reverse bindings. All gomobile bind programs must deal with the existence and breaking of reference cycles across the language barrier.

The deleted example you refer to was problematic because it tried to do an entire Android app in pure Go with the reverse bindings. It worked, but the result ended up with too many cross language cycles for that approach to be worth it for real programs.

Answer 22 · 2019-08-05T14:50:02.000Z

The deleted example you refer to was problematic because it tried to do an entire Android app in pure Go with the reverse bindings. It worked, but the result ended up with too many cross language cycles for that approach to be worth it for real programs.

Thank you for elaborating! Now I understood that reverse binding still works as same as the regular binding, but it is not feasible to write an Android application only with reverse binding due to many cycles.

Then I think we should keep the reverse binding even with modules. My current idea is that imports starting with "Java/" or "ObjC/" are special as "C" and will ignore the module information.

Answer 23 · 2019-08-09T10:22:21.000Z

Change https://golang.org/cl/189597 mentions this issue: internal/importers: replace go/build usages with go/packages

Answer 24 · 2019-08-16T03:04:42.000Z

Change https://golang.org/cl/190477 mentions this issue: cmd/gobind: remove the workaround for go/packages

Answer 25 · 2019-08-16T03:30:47.000Z

Change https://golang.org/cl/190478 mentions this issue: bind/java: make the try-bots happy

Answer 26 · 2019-08-16T04:59:15.000Z

Change https://golang.org/cl/190479 mentions this issue: cmd/gobind: fix issue at build tags

Answer 27 · 2019-08-25T05:09:49.000Z

#33822 is possible related.

Answer 28 · 2019-08-26T06:12:41.000Z

As #33807 says, Go with modules cannot understand reverse binding imports, starting with Java or ObjC, since they are not valid FQDNs. I think it is not obvious how to solve this. My current ideas are:

Fix the Go compiler to recognize imports for reverse binding
Make reverse binding valid only when GO111MODULE=off, and revisit this problem later
Give up reverse binding :-/

I think 2. is the most feasible. 1. requires specification change and would be very controversial. @hyangah, @eliasnaur, what do you think?

Answer 29 · 2019-08-26T17:05:18.000Z

@hajimehoshi let's go with 2. Go with modules can understand non-url like import path but only when they are either standard packages or packages in the main module which defines the workspace.

I will take a look at 1 this week.

Answer 30 · 2019-08-30T19:56:13.000Z

Change https://golang.org/cl/192599 mentions this issue: bind/java, bind/objc: do not use module for reverse binding

Answer 31 · 2019-09-05T07:51:10.000Z

@hyangah does this mean you're still looking for a solution to allow reverse-binding? Reverse binding is a very important feature for gomobile in my opinion.

Answer 32 · 2019-10-25T10:17:59.000Z

Change https://golang.org/cl/203397 mentions this issue: cmd/gobind: replace go/bind with go/packages in gen.go

Answer 33 · 2019-10-25T13:20:52.000Z

Change https://golang.org/cl/203399 mentions this issue: cmd/gobind: remove go/build and go/import usages from main.go

Answer 34 · 2019-11-03T20:04:59.000Z

Change https://golang.org/cl/195937 mentions this issue: cmd/gobind: add tests enabling Go modules

Answer 35 · 2019-11-12T09:18:45.000Z

Change https://golang.org/cl/206737 mentions this issue: cmd/gobind: enable TestDocs tested with Go modules

Answer 36 · 2019-11-12T10:55:32.000Z

As gobind should work with Go modules, now I'm working on gomobile bind.

gobind generates files at a temporary directory like [temp-dir]/src/gobind. The temp-dir is given by gomobile. To access this temporary package from Go modules, I think we need to do these items:

Replace go/build with go/packages as usual.
Create another temporary directory to emulate a Go proxy. This needs to zip the files and add go.mod files. See also packagestest implementation.
Give a temporary and unique module name like example.com/[random-token] to the temporary module.
Overwrite GOPROXY like $(go env GOPROXY),file:///[new-temporary-directory]
Use the temporary module name at gomobile when go building.

All are done in gomobile and gobind should not be modified from its current behavior.

@hyangah, @eliasnaur Any thoughts?

Answer 37 · 2019-11-12T12:28:08.000Z

As gobind should work with Go modules, now I'm working on gomobile bind.

gobind generates files at a temporary directory like [temp-dir]/src/gobind. The temp-dir is given by gomobile. To access this temporary package from Go modules, I think we need to do these items:
* Replace `go/build` with `go/packages` as usual.

* Create another temporary directory to emulate a Go proxy. This needs to zip the files and add `go.mod` files. See also [`packagestest` implementation](https://github.com/golang/tools/blob/master/go/packages/packagestest/modules.go#L54-L130).

Emulating a Go proxy with zip files, nice.

* Give a temporary and unique module name like `example.com/[random-token]` to the temporary module.

* Overwrite `GOPROXY` like `$(go env GOPROXY),file:///[new-temporary-directory]`

It probably doesn't matter given the random token, but perhaps swap the order so the temporary directory is first, to match the intention of gomobile bind?

* Use the temporary module name at `gomobile` when `go build`ing.
All are done in gomobile and gobind should not be modified from its current behavior.

@hyangah, @eliasnaur Any thoughts?

Sounds like a good plan to me.

Answer 38 · 2019-11-12T14:04:24.000Z

Thank you!

It probably doesn't matter given the random token, but perhaps swap the order so the temporary directory is first, to match the intention of gomobile bind?

Yes. The second item and the third item will be done at the same time, so we'd need to create a temporary directory first.

Answer 39 · 2019-11-12T15:21:07.000Z

Change https://golang.org/cl/206777 mentions this issue: cmd/gomobile: replace go/build with go/packages in bind

Answer 40 · 2019-11-15T02:24:37.000Z

@matloob I was wondering if my plan would make sense to you.

Answer 41 · 2019-11-15T20:23:10.000Z

It sounds reasonable to me.

Answer 42 · 2019-11-20T07:38:31.000Z

Change https://golang.org/cl/208059 mentions this issue: cmd/gomobile: replace go/build with go/packages in gomobile-build

Answer 43 · 2019-11-20T08:42:38.000Z

Change https://golang.org/cl/208060 mentions this issue: cmd/gomobile: remove go/build usages from build.go

Answer 44 · 2019-11-20T12:25:06.000Z

Change https://golang.org/cl/208077 mentions this issue: cmd/gobind: add -pkgpath option to gobind

Answer 45 · 2019-11-21T18:25:30.000Z

Replace go/build with go/packages as usual.

Create another temporary directory to emulate a Go proxy. This needs to zip the files and add go.mod files. See also packagestest implementation.

Give a temporary and unique module name like example.com/[random-token] to the temporary module.

Overwrite GOPROXY like $(go env GOPROXY),file:///[new-temporary-directory]

Use the temporary module name at gomobile when go building.

@hyangah and I have discussed the plan and we realized that these points:

As the package generated by gobind is a main package, the module path doesn't have to start with FQDN.
gobind command needs to output go.mod at [tmpdir]/src/gobind. This go.mod will include appropriate dependencies along withe the given packages. This depends on the environment where gobind is executed. For example, if gomobile bind example.com/foo with a go.mod specifying example.com/foo version 1.2.3 is executed, the generated go.mod would include example.com/foo v1.2.3. If gomobile bind ../relative/path/to/localmodule is executed, the go.mod would include replace directive like replace localmodule => /foo/bar/baz/relative/path/to/localmodule.
We don't need to emulate a GOPROXY server. It is because [tmpdir]/src/gobind is a main package [1]. When executing go build for the generated [tmpdir]/src/gobind package, just a relative path or changing the working directory should be fine.

Thus, the action items will be:

Replace go/build with go/packages as usual.
Fix gobind to generate an appropriate go.mod.
Fix gomobile to compile the generated [tmpdir]/src/gobind package without depending GOPATH.

@hyangah Is my understanding correct?

@eliasnaur @matloob What do you think?

[1] Even if [tmpdir]/src/gobind is not a main package, a replace directive would solve the issue.

Answer 46 · 2019-11-21T19:15:35.000Z

Thank you for summarizing the discussion. The discussion was inhttps://go-review.googlesource.com/c/mobile/+/208077.

For step 1, I think you are almost done, right? Except the reverse binding. I realized that go/packages depends on go list underneath (unless a different driver is supported). Would be nice if gobind users with different build systems can test and report issues if any.

For step 2, I'd argue that's part of gomobile bind functionality, not gobind's because gobind users may want to have control over their go.mod file, or may not need modules at all (bazel), or may want to check in the generated code with the existing module (in this case, checking in go.mod in the generated code directory by mistake can result in a multi-module repo). It may change in the future, but for now how about starting from gomobile bind?

Answer 47 · 2019-11-27T11:52:23.000Z

For step 1, I think you are almost done, right?

Right, done :-)

For step 2, I'd argue that's part of gomobile bind functionality, not gobind's because gobind users may want to have control over their go.mod file, or may not need modules at all (bazel), or may want to check in the generated code with the existing module (in this case, checking in go.mod in the generated code directory by mistake can result in a multi-module repo). It may change in the future, but for now how about starting from gomobile bind?

I think go.mod would be automatically defined by the arguments of gobind and its environment, so offering the default go.mod should not be a bad idea. I'm not sure the last case: what is a multi-module repo? Wouldn't go.mod be deterministic? We would need to discuss this more anyway.

I agree making gomobile bind care go.mod would be fine for now.

Answer 48 · 2019-11-27T13:28:04.000Z

I think go.mod would be automatically defined by the arguments of gobind and its environment, so offering the default go.mod should not be a bad idea.

Ok, how about making it an optional flag for gobind? So, gomobile bind passes the flag.

I'm not sure the last case: what is a multi-module repo? Wouldn't go.mod be deterministic? We would need to discuss this more anyway.

Multi-module repo is a repository containing multiple directories with go.mod. Then, the repo will be containing multiple repositories. Sometimes unavoidable, but often creates various problems. By accidentally dropping a go.mod in the gobind output directory, the directory will become a separate module.

Answer 49 · 2019-11-27T14:02:24.000Z

Change https://golang.org/cl/209137 mentions this issue: cmd/gomobile: specify the path to $WORK/src/gobind directly instead of using $GOPATH

Answer 50 · 2019-11-27T15:08:18.000Z

By accidentally dropping a go.mod in the gobind output directory, the directory will become a separate module.

I thought go.mod would be dropped at $WORK/src/gobind then a separate module should not be created.

Answer 51 · 2019-11-27T15:22:36.000Z

Ok, how about making it an optional flag for gobind? So, gomobile bind passes the flag.

It's ok, but I'm not sure dropping go.mod anytime would be really problematic. I'd want to avoid adding a flag if possible.

Answer 52 · 2019-12-09T05:07:51.000Z

Change https://golang.org/cl/210477 mentions this issue: cmd/gomobile: make gomobile-init support Go modules.

Answer 53 · 2019-12-17T12:17:37.000Z

I am still hitting issues while using modules

Is there a doc that tells clearly how to use gomobile bind with modules?

In my case it says its not able to find the package I am trying to build (module name in my go.mod file) in my GOPATH.

Is there a different way to give the bind command with modules? Also, I am using go1.13.

Answer 54 · 2019-12-17T12:25:14.000Z

Is there a doc that tells clearly how to use gomobile bind with modules?

Go modules is not available yet. I'm now working on this :)

Answer 55 · 2019-12-17T12:35:58.000Z

Ohh, I thought the above commit adds support for that!

Anyways, eagerly waiting for this! Thanks

Answer 56 · 2019-12-20T12:08:56.000Z

Change https://golang.org/cl/210380 mentions this issue: cmd/gomobile: enable Go modules at gomobile-bind

Answer 57 · 2020-01-13T15:33:45.000Z

Now gomobile-bind accepts Go modules (if the patch works correctly)! I'll be working on gomobile-build, and we can close this issue after that.

Answer 58 · 2020-01-13T16:01:45.000Z

Oops, I found a relative path doesn't work. I'll fix this asap.

Answer 59 · 2020-01-13T16:14:04.000Z

Change https://golang.org/cl/214497 mentions this issue: cmd/gomobile: preserve ./ when the given path is relative

Answer 60 · 2020-01-15T08:40:44.000Z

Change https://golang.org/cl/214897 mentions this issue: cmd/gomobile: enable Go modules at gomobile-build

Answer 61 · 2020-01-21T05:13:50.000Z

Change https://golang.org/cl/214498 mentions this issue: cmd/gomobile: enable Cgo

Answer 62 · 2020-01-21T05:59:59.000Z

Change https://golang.org/cl/215419 mentions this issue: cmd/gomobile: output an error message at gomobile-init

Answer 63 · 2020-01-21T07:38:10.000Z

Change https://golang.org/cl/215420 mentions this issue: cmd/gomobile: always use abolute paths to replace in go.mod

Answer 64 · 2020-01-21T07:42:09.000Z

Change https://golang.org/cl/215421 mentions this issue: cmd/gomobile: always use abolute paths to replace in go.mod

Answer 65 · 2020-01-21T11:55:30.000Z

Do replace directives work with the mod file?

I am hitting some issue where its not able to find the relative directories

Answer 66 · 2020-01-21T12:06:04.000Z

I think https://golang.org/cl/215421 will fix the issue. With this, I've confirmed replace directives worked.

Answer 67 · 2020-01-23T02:51:46.000Z

Now all the problems I found have been fixed. Let's close this issue (I don't have the right to close this issue though), and file other issues when we find other problems.

Answer 68 · 2020-01-23T03:56:11.000Z

Great work @hajimehoshi !

Answer 69 · 2020-02-17T12:37:32.000Z

Thanks a lot @hajimehoshi !

Answer 70 · 2020-02-17T14:20:14.000Z

Forgive my lack of understanding - will this ship with a particular version of Go? I see it’s still part of an “Unreleased” milestone.

Answer 71 · 2020-02-17T15:02:09.000Z

@themartorana x/mobile is a repository and a module that you can use today. It's not shipped with Go releases, nor does it follow its release schedule. If a new version of gomobile is out, you can use it with Go 1.13.8, just like you can use it with 1.14rc1.

Answer 72 · 2020-03-16T17:49:07.000Z

@hajimehoshi Oh wow, so happy to see this closed. Buuut :D, I think I found a tiny case that could use some love. gomobile doesn't seem to cache binaries across builds. I have a dependency that takes 5-7 minutes to build for a single platform (https://github.com/ipsn/go-libtor), so for all 4, that's a whopping 30. That's acceptable if it gets reused for subsequent builds, but unfortunately currently it does not. Would it be possible to keep the build cache around?

Answer 73 · 2020-03-16T18:13:29.000Z

Thanks.

gomobile doesn't seem to cache binaries across builds.

That's odd since gomobile just invokes go commands as usual and then module cache and build cache should be used.

I was wondering if my fix was the culprit of the issue you reported. Hasn't there been this issue before my fix?

Answer 74 · 2020-03-16T18:39:56.000Z

That's odd since gomobile just invokes go commands as usual and then module cache and build cache should be used.

Isn't gomobile using custom build and cache dirs? The packages are definitely downloaded into the tmp folder under gomobile-work-xxxxxxxx, new for every build.

Hasn't there been this issue before my fix?

I can't say, it's been a while since I picked up gomobile. Started doing it today. If you're looking for a painful repro, here's the code I just pushed https://github.com/coronanet/go-coronanet . Though it would possibly make sense to use something smaller to test than this monstrosity.

Answer 75 · 2020-03-17T13:48:13.000Z

Isn't gomobile using custom build and cache dirs? The packages are definitely downloaded into the tmp folder under gomobile-work-xxxxxxxx, new for every build.

Aha, gobind, which is invoked by gomobile, generates a source code from Go packages for binding, and they are not cached indeed. Did you mean 'cache' of them?

Answer 76 · 2020-03-17T13:49:16.000Z

I think the cache issue is not related to this issue #27234, so I'd be happy if you could file a new issue.

Answer 77 · 2020-03-17T16:02:43.000Z