This is is a follow-up from my previous PR (#65). It makes gomobile
aware of GOOS=ios and adds support for specifying specific Apple
platforms, instead of overloading the "ios" platform.
Supported platforms: ios, iossimulator, macos, and maccatalyst
These can now be specified the -target argument to gomobile, e.g.:
gomobile build -target=ios,iossimulator,macos,maccatalyst
It preserves the current behavior of -target=ios, which will build for
ios and iossimulator on supported architectures (arm64 and amd64).
It adds platform-specific build tags so Go code can discriminate between
different Apple platforms like maccatalyst (UIKit on macOS).
This PR also fixes a number of broken tests.
TODO: cgo has a bug where c-archive builds targeting Catalyst will fail
unless -tags=ios is supplied. See https://golang.org/issues/47228
Fixes https://golang.org/issues/47212
Updates https://golang.org/issues/47228
Change-Id: Ib1a2f5302c5edd0704c13ffbe8f4061211f50d4e
GitHub-Last-Rev: 01ab28e63fe6890a9f9783e3fc41b1c895b0274d
GitHub-Pull-Request: golang/mobile#70
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/334689
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Hajime Hoshi <hajimehoshi@gmail.com>
This change permits gomobile to build iOS applications by properly
set GOOS=ios in the build process. The change is locally tested on
darwin/arm64, and golang.org/x/mobile/example/basic can be build
using the following commands:
gomobile build -target=android -o=basic.apk \
golang.org/x/mobile/example/basic
gomobile build -target=ios -bundleid=org.golang.gomobiletest \
-o=basic.app golang.org/x/mobile/example/basic
The built binaries are also tested on iOS 15 beta7 and Android 12 API31.
Updates golang/go#47952Fixesgolang/go#47238
Change-Id: Ibf40a77933ac957640c78d0dbc1af043477e4b3a
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/346150
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Go 1.15 no longer supports darwin/arm. arm64 is still supported by
Android and iOS.
Updates golang/go#39575
Change-Id: I91f09477ae68de148e4d63eef38d7d28f553d16c
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/241717
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this change, the main module specifies the module version of the
package to bind, the version might not be adopted by gomobile because
gomobile trims some dependencies information. If a dependency is not
a main module nor a replaced module, the dependency information is
omitted.
For example, if you have this go.mod in a workspace:
module example.com/m
requier (
github.com/foo/bar v0.1.0-123456
)
and then run `gomobile bind github.com/foo/bar` there, the specified
version might not be used because github.com/foo/bar is not a main nor
a replaced module.
This change keeps the dependency information as much as possible
to avoid this confusion.
Updates golang/go#37048
Change-Id: I875a1b9485438bdee336f3fc2d131775353004f5
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/226279
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Previously, gomobile bind's go.mod generation logic assumed
replacing module was always located in the disk, but is not
always true. It's valid to replace a module(version) with
another module&version.
For example,
replace golang.org/x/tools => ../
causes:
{
"Path": "golang.org/x/tools",
"Version": "v0.0.0-20191017151554-a3bc800455d5",
"Replace": {
"Path": "../",
"Dir": "/usr/local/google/home/hakim/go/src/golang.org/x/tools",
"GoMod": "/usr/local/google/home/hakim/go/src/golang.org/x/tools/go.mod",
"GoVersion": "1.11"
},
"Dir": "/usr/local/google/home/hakim/go/src/golang.org/x/tools",
"GoMod": "/usr/local/google/home/hakim/go/src/golang.org/x/tools/go.mod",
"GoVersion": "1.11"
}
replace github.com/anacrolix/torrent v1.13.0 => gitlab.com/axet/torrent v0.0.0-20200205141541-92b4b9e7387e
causes:
{
"Path": "github.com/anacrolix/torrent",
"Version": "v1.13.0",
"Replace": {
"Path": "gitlab.com/axet/torrent",
"Version": "v0.0.0-20200205141541-92b4b9e7387e",
"Time": "2020-02-05T14:15:41Z",
"Dir": "/usr/local/google/home/hakim/go/pkg/mod/gitlab.com/axet/torrent@v0.0.0-20200205141541-92b4b9e7387e",
"GoMod": "/usr/local/google/home/hakim/go/pkg/mod/cache/download/gitlab.com/axet/torrent/@v/v0.0.0-20200205141541-92b4b9e7387e.mod"
},
"Dir": "/usr/local/google/home/hakim/go/pkg/mod/gitlab.com/axet/torrent@v0.0.0-20200205141541-92b4b9e7387e",
"GoMod": "/usr/local/google/home/hakim/go/pkg/mod/cache/download/gitlab.com/axet/torrent/@v/v0.0.0-20200205141541-92b4b9e7387e.mod"
}
Also, while we are here, trim down the entries added to the generated
go.mod. We need the main module, and the replaced module info.
We may want to pin golang.org/x/mobile version if possible, but I don't
know a reliable way to achieve that yet.
Fixesgolang/go#37048
Change-Id: Ibd7332338c0a3c4165a642c3e86852061f6ab13b
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/218057
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
A replative path in go.mod works only in the directory of the
go.mod. When creating go.mod for gobind, copying relative paths
did not work since go.mod is in a different temporary directory.
This CL fixes the issue to use Dir, which is an absolute path to
the module, instead of Path.
Updates golang/go#27234
Change-Id: Ib009ec508aa3ce3d092af14f921a57192feaac61
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/215421
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL gives CGO_ENABLED=1 explicitly when executing gobind since
Cgo is disabled by default when GOOS is given.
This CL also adds importing C to the tests to confirm that Cgo
works correctly.
This CL also updates go.mod since this change requries the change
in go/packages: golang.org/cl/214943
Updates golang/go#27234
Updates golang/go#36547
Change-Id: I66f9697f992f15b52fca7871e4e0ed64ca2b4965
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/214498
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This was introduced at https://go-review.googlesource.com/c/mobile/+/191518
originally, but this change was against the decision at
golang/go#26845.
"go" always works even when Go command that name is not "go", like
"go1.14beta1" is used. See also the discussion at golang/go#28043
Change-Id: Ifebe969edaeda0373b2840d25a4f4030509176fa
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/214898
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This CL fixes an issue that a relative path didn't work with
gomobile. path.Clean removed the prefix './' and this was too
aggressive. path.Clean was needed for go/build.Context.Import
(see golang/go#18876), but they have already been replaced with
packages.Load, so clearning paths is no longer needed.
Updates golang/go#27234
Change-Id: Ife28da6d845baaf94e627a7a44a5e962b8a1d013
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/214497
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL enables Go modules in gomobile-bind command. This CL
generates go.mod at $WORK/src based on the modules state of the
working directory, and use it when executing go-build.
Updates golang/go#27234
Change-Id: I6958f29a317c0d2fb9ffa373f6e3c4cabdc4e898
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/210380
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL is a pure refactoring. This removes a global variable ctx,
which is a build.Default.
Before this change, ctx was used to keep build tags and its state
affected go command executions. As the variable is mutable, the
code was not readable.
This changes introduces another global variable buildTags instead,
but this is more consistent with other build flags, and this is
immutable.
Updates golang/go#27234
Change-Id: Id8d0c779de21b249e96febd2f40833cd0c84534f
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/208060
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This is a preparation to use Go modules at gomobile command.
Updates golang/go#27234
Change-Id: I8ee47cb53f5b748592a0c8c9f383abab27a7fdad
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/208059
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This is a preparation to use Go modules at gomobile-bind.
Updates golang/go#27234
Change-Id: I33684888b4181cc1ebd4d3c8872a6b2e62950855
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/206777
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Add the "-trimpath" flag from Go 1.13.
Change-Id: I10938fb5f7efd701f4025e451ddf438dc3e011ee
GitHub-Last-Rev: 4e82381342e2c13c318514800bc82af7f6ed9e1a
GitHub-Pull-Request: golang/mobile#39
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/196877
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
To use the NDK before version r19b standalone toolchains had to be
generated. Version r19b added prebuilt standalone toolchains.
Use the prebuilt for gomobile build and gomobile bind and
stop generating toolchains during gomobile init.
gomobile init is now only necessary for building OpenAL for
gomobile build programs.
This change is not compatible with NDK versions < r19b, but the
user is instructed how to upgrade when running gomobile build or
gomobile bind.
Change-Id: I96953298ecce42402459a9dd15169c09fe6b6f8b
Reviewed-on: https://go-review.googlesource.com/c/163378
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
CL 99316 changed gobind to be platform independent, so
standalone bindings could be generated without having the
Android and Xcode SDKs installed. However, bindings that does
depend on GOOS for its exported API, in particular go source
files that use Cgo now only works if the exported API is
extracted to platform independent files.
By switching to use the source importer, importer.For("source", nil),
gobind can type check the bound packages even in the presence of
Cgo.
The source importer in Go 1.9 and 1.10 has problems with relative
imports and imports from testdata directories (issues 23092 and 24392),
but works from Go 1.10.1 on.
Fixesgolang/go#24856
Change-Id: Icb18dce15325b7d4e58cabc1181051bc6269fc1f
Reviewed-on: https://go-review.googlesource.com/99777
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Bindings are independent of any particular GOOS/GOARCH pair and
as such the gomobile bind command doesn't set GOOS nor GOARCH when
running gobind. However, the ios tag was still added to the list
of tags to pass to gobind for -target=ios.
Move the ios tag to when actually building the bound packages,
mirroring gomobile build.
Add TestBindIOS and update TestBindAndroid.
Updates golang/go#24644
Change-Id: I007829c26036427a3376bba11a1ccb86e7338848
Reviewed-on: https://go-review.googlesource.com/104458
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
While we're here, add 386 to the list of supported architectures
on iOS.
To support gomobile build for amd64 and 386, use the "ios" tag to
distinguish between iOS and macOS builds.
Change-Id: Ie09a432794bd8d9853950115349f8d3b57cf43f5
Reviewed-on: https://go-review.googlesource.com/102915
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When running gomobile bind, make sure gobind exists. If not, instruct
the user to run gomobile init which will go install gobind.
Change-Id: I2d064ba58874fd5581c17417124561f3d1fb6b83
Reviewed-on: https://go-review.googlesource.com/101055
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Issue golang/go#24058 demonstrates a Go package that fails to build with
gomobile but builds successfully with a manually using the standalone NDK
toolchain. I haven't been able to figure out a set of CPPFLAGS/LDFLAGS
that fixes the build for 24058 so instead rework gomobile to use
standalone NDK toolchains.
Standalone toolchains fixes the 24058 build and is the official way
to build Android programs. So gomobile should be less affected by
future changes in the NDK toolchain internals.
Create the standalone toolchains with gomobile init.
With the new Go 1.10 build cache, the prebuild work by the gomobile
init command is useless. Use the opportunity to simplify init to
only creating NDK toolchains and, optionally, building OpenAL for
Android. With that, it is no longer necessary to use gomobile init
to build iOS apps and frameworks.
Fixesgolang/go#24058
Change-Id: I4692fcaa927e7076a6387d080ebc1726905afd72
Reviewed-on: https://go-review.googlesource.com/99875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind and gomobile bind tools have historically overlapped:
gobind outputs generated bindings, and gomobile bind will generate
bindings before building them. However, the gobind bindings were
never used for building and thus allowed to not be complete.
To simplify version control, debugging, instrumentation and build
system flexibility, this CL upgrades the gobind tool to be the
canonical binding generator and change gomobile bind to use gobind
instead of its own generator code.
This greatly simplifies gomobile bind, but also paves the way to skip
gomobile bind entirely. For example:
$ gobind -outdir=$GOPATH golang.org/x/mobile/example/bind/hello
$ GOOS=android GOARCH=arm64 CC=<ndk-toolchain>/bin/clang go build -buildmode=c-shared -o libgobind.so gobind
$ ls libgobind.*
libgobind.h libgobind.so
The same applies to iOS, although the go build command line is more
involved.
By skipping gomobile it is possible to freely customize the Android
or iOS SDK level or any other flags not supported by gomobile bind.
By checking in the generated source code, the cost of supporting
gomobile in a custom build system is also decreased.
Change-Id: I59c14a77d625ac1377c23b3213672e0d83a48c85
Reviewed-on: https://go-review.googlesource.com/99316
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The default ObjC prefix and Java package have been the empty string
for a while, but the gomobile bind -help text wasn't updated.
Change-Id: I8acb265ae7385121fae4c2cc314220d97575d20c
Reviewed-on: https://go-review.googlesource.com/99317
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Convert Go documentation to JavaDoc tags (/** ... */).
Since the .aar file format doesn't support source files, gomobile
will create a package-sources.jar along with the main package.aar.
For Objective-C, JavaDoc-style comments seems to work as well,
judging by manual inspection of Xcode quick help.
Change-Id: I47fe5b6804681d459a873be37a44610d392166ef
Reviewed-on: https://go-review.googlesource.com/52330
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Clean the package paths so gomobile use the same directory for the
export data (*.a) files as the go tool.
Fixesgolang/go#18876.
Change-Id: I40285f9203f04dbb80b21bd74d9b24212b677533
Reviewed-on: https://go-review.googlesource.com/37323
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
For Java classes implemented in Go, it is useful to take a Java instance
and extract its wrapped Go instance. For example, consider the
java.lang.Runnable implementation wrapping a Go function:
package somepkg
type GoRunnable struct {
lang.Runnable
f func()
}
Java methods that take a java.lang.Runnable cannot directly take a
*GoRunnable, so this CL adds a Unwrap method:
import gorun "Java/somepkg/GoRunnable"
...
r := gorun.New()
r.Unwrap().(*GoRunnable).f = func() { ... }
javapkg.Run(r)
The extra interface conversion is unfortunately needed to avoid
import cycles.
Change-Id: Ib775a5712cd25aa75a19d364a55d76b1e11dce77
Reviewed-on: https://go-review.googlesource.com/35295
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Gomobile has up until now used stripped NDKs hosted by Google. This
arrangement adds maintenance overhead and blocks the use of custom
NDKs or custom API levels. Also, as noted in issue 16211, the stripped
NDK is no longer tiny because Gomobile supports more platforms.
This CL removed the code for generating and packaging stripped NDKs and
adds support for using external NDKs to the gomobile tool.
gomobile init will now use the NDK installed by the Android SDK manager,
if present, or a user specified NDK if the -ndk flag is given. If no
NDK was found or specified, Android initialization is skipped. gomobile
will instruct the user to run init with a valid NDK if bind or build is
invoked without Android initialization.
gomobile init will also attempt to build OpenAL for Android if the -openal
flag specifies a source directory. It needs cmake and, on Windows, nmake
installed. If gomobile build is run on an app that requires
golang.org/x/mobile/exp/audio/al and OpenAL wasn't built by init, the user
is instructed to do so.
Tested on Linux, macOS, Windows.
Fixesgolang/go#16211Fixesgolang/go#18522
Change-Id: Ia38f6e43e671a207dad562678c65225b426e7e3e
Reviewed-on: https://go-review.googlesource.com/35173
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The gomobile tool mishandled build tags in two ways, first by
ignoring tags for iOS, second by passing multiple tags along to
the go tool incorrectly. This CL fixes both.
Fixesgolang/go#18523Fixesgolang/go#18515
Change-Id: I28a49c1e23670adb085617d9f5fb5cd5e22a4b65
Reviewed-on: https://go-review.googlesource.com/34955
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is the Objective-C equivalent of CL 34776, generating reverse
wrappers for generated ObjC types. The implementation follows the same
strategy as the Java implementation: use the Go ast package to find
exported structs with embedded Objective-C types and synthesize their
types as if they were imported through clang.
In turn, the handling of the implicit "self" parameter changes in the
same way as well: the type of self parameters must be the wrapped type
for the generated type. For example:
func (d *GoNSDate) Description(self Foundation.NSDate) string
becomes
import gopkg "ObjC/Objcpkg"
func (d *GoNSDate) Description(self gopkg.GoNSDate) string
Change-Id: I26f838b06a622864be463f81dbb4dcae76f70f20
Reviewed-on: https://go-review.googlesource.com/34780
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The Objective-C bindings was recently changed to support the empty
name prefix and to use that as the default. This CLs changed the Java
generators in the same way, supporting the empty Java package and using
it as the default.
Change-Id: I857affce686c67638a2b6c4e1da5d6a88d7ba560
Reviewed-on: https://go-review.googlesource.com/34778
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, the type of the implicit "this" parameter to Java methods
implemented in Go could only be a super class of the generated Java
class. For example, the following GoRunnable type is an implementation of
the Java interface java.lang.Runnable with a toString method:
package somepkg
import "Java/java/lang"
type GoRunnable struct {
lang.Runnable
}
func (r *GoRunnable) ToString(this lang.Runnable) string {
...
}
The "this" parameter is implicit in the sense that the reverse generator
automatically fills it with a reference to the Java instance of
GoRunnable.
Note that "this" has the type Java/java/lang.Runnable, not
Java/go/somepkg.GoRunnable, which renders it impossible to call Java
methods and functions that expect GoRunnable. The most practical example
of this is the Android databinding libraries.
This CL changes the implicit this parameter to always match the exact
type. In the example, the toString implementation becomes:
import gopkg "Java/go/somepkg"
func (r *GoRunnable) ToString(this gopkg.GoRunnable) string {
...
}
One strategy would be to simply treat the generated Java classes
(GoRunnable in our example) as any other Java class and import it
through javap. However, since the Java classes are generated after
importing, this present a chicken-and-egg problem.
Instead, use the newly added support for structs with embedded prefixed types
and synthesize class descriptors for every exported Go struct type.
Change-Id: Ic5ce4a151312bd89f91798ed4088c9959225b448
Reviewed-on: https://go-review.googlesource.com/34776
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Since generated names now have their package names prefixed, the
extra prefix, "Go", is both confusing and counter-productive to
making the generated ObjC code look like any other native code.
Change the default to the empty prefix, while preserving support
for an explicit prefix if needed.
This is a backwards incompatible change; to keep the old behaviour,
specify "-prefix Go" to the gobind or gomobile command.
While we're here, fix the Ivy example for the recent change in
error returns.
Change-Id: I7fef4a92a18ddadee972ccf359652e3b31624f33
Reviewed-on: https://go-review.googlesource.com/34643
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since the Go package name is already prefixed to generated ObjC
names, the empty extra prefix is useful. Support that by not reverting
to the default extra prefix, "Go", if -prefix "" is specified.
To avoid file name clashes with the Go header files, add ".objc" to
the ObjC-facing header names.
Change-Id: I559fe60d7474521617f23894af247c6019ff2a21
Reviewed-on: https://go-review.googlesource.com/33954
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Accept ObjC API wrapper types as arguments and return values from
bound Go package functions and methods. Also, allow Go structs
to extend ObjC classes and implement ObjC protocols as well as override
and implement methods.
This is the third and final part of the implementation of the golang/go#17102
proposal.
Fixesgolang/go#17102
Change-Id: I601d90fb6d22b8d6f8b7d5fe0130daa1a4dd4734
Reviewed-on: https://go-review.googlesource.com/29175
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Using the new ObjC type analyzer API, scan the bound packages for
references to ObjC classes and protocols and generate Go wrappers for them.
This is the second part of the implementation of proposal golang/go#17102.
For golang/go#17102
Change-Id: I773db7b0362a7ff526d0a0fd6da5b2fa33301144
Reviewed-on: https://go-review.googlesource.com/29174
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Output every Java class, including the support classes, from gobind
-lang=java. In addition, replace Go package export data parsing with
converting from go/ast to go/types. That way, gobind can tolerate
unknown imports as long as the exported Go API doesn't use them.
In a follow-up CL, the gobind gradle plugin will use gobind for a first
pass to expose the generated Java classes to the android plugin.
Change-Id: I8134899ec818c7fee79e4d9df8afcae9dd679add
Reviewed-on: https://go-review.googlesource.com/30093
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Add -bootclasspath and -classpath flags to the gomobile tool. In a
follow-up CL, the gobind gradle plugin will use them to support R and
databinding classes from Go.
Change-Id: Id33acf0c3fe1ec3908740b2a736ed241fa6391c2
Reviewed-on: https://go-review.googlesource.com/30092
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Accept Java API interface types as arguments and return values from
bound Go package functions and methods. Also, allow Go structs
to extend Java classes and implement Java interfaces as well as override
and implement methods.
This is the third and final part of the implementation of the golang/go#16876
proposal.
Fixesgolang/go#16876
Change-Id: I6951dd87235553ce09abe5117a39a503466163c0
Reviewed-on: https://go-review.googlesource.com/28597
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Using the new Java class analyzer API, scan the bound packages
for references to Java classes and interfaces and generate Go
wrappers for them.
This is the second part of the implementation of proposal golang/go#16876.
For golang/go#16876
Change-Id: I59ec0ebdae0081a615dc34d450f344c20c03f871
Reviewed-on: https://go-review.googlesource.com/28596
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, generated Java classes or interfaces were inner
classes to the top package class. That is both unnecessary and creates
ugly class names. Instead, move every generated class and interface to its
own package level class.
NOTE: This is a backwards incompatible change and requires every client
of gomobile APIs to be updated to leave out the package class in the
type names. For example, the Go type
package pkg
type S struct {
}
now generates (with the default java package name go) a Java class named
go.pkg.S. The name before this CL was go.pkg.Pkg.S.
Also, change the custom java package to specify the package prefix and
not the full package as before. This is an unfortunate change needed
to avoid name clashes between two bound packages. On the plus side,
the change brings the custom package case closer to the default behaviour,
which is a commen prefix, "go.", and a distinct java package for every
Go package bound.
Change-Id: Iadfaad56e101d1caf7e2a05006f4d384859a20fe
Reviewed-on: https://go-review.googlesource.com/27436
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Gobind uses strings for passing errors across the language barrier.
However, since Gobind doesn't have a concept of a nil string, it
can't separate an empty native string from a nil string.
In turn, that means that empty errors, exceptions or NSError * with
an empty description are treated as no error. With ObjC, empty errors
are replaced with a default string to workaround the issue, while
with Java empty errors are silently ignored.
Fix this by replacing strings with actual error objects, wrapping
the Go error, Java Throwable or ObjC NSError *, and letting the
existing bind machinery take care of passing the references across.
It's a large change for a small corner case, but I believe objects
are a better fit for exception that strings. Error objects also
naturally leads to future additions, for example accessing the
exception class name or chained exception.
Change-Id: Ie03b47cafcb231ad1e12a80195693fa7459c6265
Reviewed-on: https://go-review.googlesource.com/24100
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Java classes must explicitly declare implemented interfaces. Bind
already declares all such interfaces within each package. Expand
the set of interfaces to include all bound packages.
In addition, let Java interfaces extend all possible interfaces in
the same way as Java classes. To avoid circular references, only
let interfaces extend compatible interfaces with fewer methods.
Before, each package was imported in its own importer, breaking the
assumption of types.AssignableTo that identical packages have
identical *types.Package. Fix that by using one importer for all
bound packages, replacing package path equality checks with direct
equality checks.
While we're here, add missing arguments to a few error messages.
Change-Id: I5eb58972a3abe918862ca99d5a203809699a3433
Reviewed-on: https://go-review.googlesource.com/20987
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Multiple packages are already supported, but only as if each packages
were bound in isolation. This CL lets a bound package refer to other
bound packages in its exported functions, types and fields.
In Java, the JNI class jclass and constructor jmethodID are exported
so other packages can construct proxies of other packages' interfaces.
In ObjC, the class @interface declarations are moved from the package
.m file to its .h file to allow other packages to constructs its
interface proxies.
Add a supporting test package, secondpkg, and add Java and ObjC tests
for the new cross package functionality. Also add simplepkg for
testing corner cases where the generated Go file must not include its
bound package.
While we're here, stop generating Go proxy types for struct types;
only Go interfaces can be implemented in the foreign language.
Change-Id: Icbfa739c893703867d38a9100ed0928fbd7a660d
Reviewed-on: https://go-review.googlesource.com/20575
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The seq serialization machinery is a historic artifact from when Go
mobile code had to run in a separate process. Now that Go code is running
in-process, replace the explicit serialization with direct calls and pass
arguments on the stack.
The benefits are a much smaller bind runtime, much less garbage (and, in
Java, fewer objects with finalizers), less argument copying, and faster
cross-language calls.
The cost is a more complex generator, because some of the work from the
bind runtime is moved to generated code. Generated code now handles
conversion between Go and Java/ObjC types, multiple return values and memory
management of byte slice and string arguments.
To overcome the lack of calling C code between Go packages, all bound
packages now end up in the same (fake) package, "gomobile_bind", instead of
separate packages (go_<pkgname>). To avoid name clashes, the package name is
added as a prefix to generated functions and types.
Also, don't copy byte arrays passed to Go, saving call time and
allowing read([]byte)-style interfaces to foreign callers (#12113).
Finally, add support for nil interfaces and struct pointers to objc.
This is a large CL, but most of the changes stem from changing testdata.
The full benchcmp output on the CL/20095 benchmarks on my Nexus 5 is
reproduced below. Note that the savings for the JavaSlice* benchmarks are
skewed because byte slices are no longer copied before passing them to Go.
benchmark old ns/op new ns/op delta
BenchmarkJavaEmpty 26.0 19.0 -26.92%
BenchmarkJavaEmptyDirect 23.0 22.0 -4.35%
BenchmarkJavaNoargs 7685 2339 -69.56%
BenchmarkJavaNoargsDirect 17405 8041 -53.80%
BenchmarkJavaOnearg 26887 2366 -91.20%
BenchmarkJavaOneargDirect 34266 7910 -76.92%
BenchmarkJavaOneret 38325 2245 -94.14%
BenchmarkJavaOneretDirect 46265 7708 -83.34%
BenchmarkJavaManyargs 41720 2535 -93.92%
BenchmarkJavaManyargsDirect 51026 8373 -83.59%
BenchmarkJavaRefjava 38139 21260 -44.26%
BenchmarkJavaRefjavaDirect 42706 28150 -34.08%
BenchmarkJavaRefgo 34403 6843 -80.11%
BenchmarkJavaRefgoDirect 40193 16582 -58.74%
BenchmarkJavaStringShort 32366 9323 -71.20%
BenchmarkJavaStringShortDirect 41973 19118 -54.45%
BenchmarkJavaStringLong 127879 94420 -26.16%
BenchmarkJavaStringLongDirect 133776 114760 -14.21%
BenchmarkJavaStringShortUnicode 32562 9221 -71.68%
BenchmarkJavaStringShortUnicodeDirect 41464 19094 -53.95%
BenchmarkJavaStringLongUnicode 131015 89401 -31.76%
BenchmarkJavaStringLongUnicodeDirect 134130 90786 -32.31%
BenchmarkJavaSliceShort 42462 7538 -82.25%
BenchmarkJavaSliceShortDirect 52940 17017 -67.86%
BenchmarkJavaSliceLong 138391 8466 -93.88%
BenchmarkJavaSliceLongDirect 205804 15666 -92.39%
BenchmarkGoEmpty 3.00 3.00 +0.00%
BenchmarkGoEmptyDirect 3.00 3.00 +0.00%
BenchmarkGoNoarg 40342 13716 -66.00%
BenchmarkGoNoargDirect 46691 13569 -70.94%
BenchmarkGoOnearg 43529 13757 -68.40%
BenchmarkGoOneargDirect 44867 14078 -68.62%
BenchmarkGoOneret 45456 13559 -70.17%
BenchmarkGoOneretDirect 44694 13442 -69.92%
BenchmarkGoRefjava 55111 28071 -49.06%
BenchmarkGoRefjavaDirect 60883 26872 -55.86%
BenchmarkGoRefgo 57038 29223 -48.77%
BenchmarkGoRefgoDirect 56153 27812 -50.47%
BenchmarkGoManyargs 67967 17398 -74.40%
BenchmarkGoManyargsDirect 60617 16998 -71.96%
BenchmarkGoStringShort 57538 22600 -60.72%
BenchmarkGoStringShortDirect 52627 22704 -56.86%
BenchmarkGoStringLong 128485 52530 -59.12%
BenchmarkGoStringLongDirect 138377 52079 -62.36%
BenchmarkGoStringShortUnicode 57062 22994 -59.70%
BenchmarkGoStringShortUnicodeDirect 62563 22938 -63.34%
BenchmarkGoStringLongUnicode 139913 55553 -60.29%
BenchmarkGoStringLongUnicodeDirect 150863 57791 -61.69%
BenchmarkGoSliceShort 59279 20215 -65.90%
BenchmarkGoSliceShortDirect 60160 21136 -64.87%
BenchmarkGoSliceLong 411225 301870 -26.59%
BenchmarkGoSliceLongDirect 399029 298915 -25.09%
Fixesgolang/go#12619Fixesgolang/go#12113Fixesgolang/go#13033
Change-Id: I2b45e9e98a1248e3c23a5137f775f7364908bec7
Reviewed-on: https://go-review.googlesource.com/19821
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Not updated the doc yet.
Not useful for iOS yet.
For golang/go#10743
Change-Id: Iaffc41af2c876aa5889c44aae459241af9ec206e
Reviewed-on: https://go-review.googlesource.com/17580
Reviewed-by: David Crawshaw <crawshaw@golang.org>
