go: x/mobile: build failing when using go modules

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.

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.

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?

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 😃

Are there any workarounds for the meantime?

Great work @hajimehoshi !

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:

1. Fix the Go compiler to recognize imports for reverse binding
2. Make reverse binding valid only when GO111MODULE=off, and revisit this problem later
3. 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?

CC @hyangah

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

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

1. Fix gobind to work with Go modules
2. Fix gomobile-bind to work with Go modules
3. 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?

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.

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

@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.

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

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

@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.

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

@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.