CC @hyangah

I would like to keep separate binaries. gobind generates a source code and gomobile generates an application or a shared library, so they are different.

In the context of Go modules, gobind is obvious how to fix for Go module, while gomobile is not.

Commands go build, go test, go tool pprof etc. are all doing different things but are under one binary. One cmd for gomobile would be more clear as you should not split into separate binaries if you have different output but all commands are related to it's general purpose to compile, link, generate code for mobile native apps.

Commands go build, go test, go tool pprof etc. are all doing different things but are under one binary.

Sorry if I'm wrong, but some of the Go tools you mentioned are separated binaries.

https://golang.org/src/cmd/

Here is example https://github.com/golang/go/blob/master/src/cmd/go/main.go#L43 how different tools are used with go command. In the end they can be both as separate binaries and reused for main binary command.

/cc @hyangah @eliasnaur

ping @hyangah and @eliasnaur again. Any thoughts?

/cc @steeve

SGTM.

SGTM, as long as the functionality is kept (we use it in https://github.com/znly/rules_gomobile).
It makes it for the slightly more complex build [1], but nothing major.

1. https://github.com/znly/rules_gomobile/tree/master/third_party/org_golang_x_mobile

SGTM eventually, but not sure who will work on and who will maintain.

IIRC, gomobile originally invoked the bind library. But as it became more complex and major users of go mobile binding move out of gomobile and the development focus was moved more on gobind itself, gomobile was changed to simply invoke gobind for easier code maintenance.

code maintenance

I assume this proposal is about merging the binaries, not the code. The bind code stays in a separate package.

I assume this proposal is about merging the binaries, not the code. The bind code stays in a separate package.

ping @hyangah

cmd/gobind was originally capturing a bigger concept - providing a general binding facility beyond android/ios. (python, java for general use, etc.). cmd/gomobile assumes a particular code layout and a specific build tool setup (go, ndk, xcode) and provides an easy-to-access tool for beginners. Thus, I feel this proposal is a bit reversed (like merging compile code logic to go, etc).

• What made it difficult to make the majority of the gobind logic a library and make the gomobile simply call the library instead of invoking the cmd/gobind binary, and the cmd/gobind binary simply wraps the library?

Once we can make the library (probably internal) and succeed to make cmd/gobind minimal, I think we will be in a better position to make this decision.

• gobind and gomobile bind flags look different. can someone layout more detailed plans on merge those flags and avoid confusion?