This is not to say that iOS support in the gomobile tool is "ready",
but it is working well enough to qualify as the same level of
experimental as the rest of the tool.
Change-Id: I7aab7a5072b23f051501bbb6bbecdb9c449296a5
Reviewed-on: https://go-review.googlesource.com/12892
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This breaks our dependency on the x/tools repository, which has a
tendency to change in unexpected ways. It also means we can use the
version of go/types that ships with Go 1.5.
Along the way, it appears that cgo processing has changed slightly.
The old check for cgo files apparently wasn't working, so I removed
it.
Change-Id: I14378e9df9cd65c5ab61b47728ba0d56f31cdf76
Reviewed-on: https://go-review.googlesource.com/12680
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Looks like the binary is present on OS X even when Java is not
installed, and it returns an error when called.
Change-Id: Icbd42637f718a4fc05e65ea3973a584d1f24850e
Reviewed-on: https://go-review.googlesource.com/12743
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
In order to make the artifacts of go build command preserved under WORK
directory, this change modifies TMPDIR (TEMP/TMP for windows)
environment variables to point to gomobile's tmpdir if -work flag is set.
> gomobile init -work
WORK=/gopath/pkg/gomobile/work-276689736
> ls /gopath/pkg/gomobile/work-276689736
README go-build823903592 openal
android-ndk-r10e go-build858075903
go-build365743399 go-build921886344
> gomobile build -work golang.org/x/mobile/example/basic
WORK=/tmp/gomobile-work-863381843
> ls /tmp/gomobile-work-863381843
go-build102034516 libbasic.so
> gomobile bind -work github.com/hyangah/ivy
WORK=/tmp/gomobile-work-355100962
> ls /tmp/gomobile-work-355100962
android go-build284034365 javac-output
androidlib go_ivy
Change-Id: I2f467e0063bc1c8b8c636a8cd6d100e86a99a91a
Reviewed-on: https://go-review.googlesource.com/12720
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Builders only have p=4.
Change-Id: I3e5d57579d26cb26f4ce29817a7bbdd8c34ad2ae
Reviewed-on: https://go-review.googlesource.com/12742
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Today we only look at direct imports of package main for an import of
golang.org/x/mobile/app, which is unfortunate. We also do a complete
package tree load using go/build looking for the OpenAL import when
building for android, which involves reading a lot of files.
The compiler and linker have already done all of this work for us.
Run nm on the output binary and extract package names from it.
Change-Id: Ie4f07befede5017bbca7d24325062369d4b5c30d
Reviewed-on: https://go-review.googlesource.com/12645
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This deflakes the TestIOSBuild test, which relies on the iteration
order. While here, use the existing contents to shorten the test
output comparison.
Fixesgolang/go#11889
Change-Id: Ib8c9592d07c53a12eee1f40267eaa2074b8d71cc
Reviewed-on: https://go-review.googlesource.com/12679
Reviewed-by: Burcu Dogan <jbd@google.com>
gomobile init should force download the NDK or the OpenAL package
if -u is set. -x should not print `curl` lines if cached archives
are being used.
Change-Id: I82ceb28540c22a0579ba9969bcf11477f1da81fb
Reviewed-on: https://go-review.googlesource.com/12701
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This lets `gomobile build` work on a package that contains files all
protected as '// +build android'.
Change-Id: I22915aecda8674597cfe18e1f75d30e6bfc4aab7
Reviewed-on: https://go-review.googlesource.com/12640
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Drops the time for `gomobile init` on my machine from 46s to 30s.
Change-Id: Iab89f2e1d1cee4b414dc2fb1c735b4167aef9036
Reviewed-on: https://go-review.googlesource.com/12641
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Finding the revision info from compiled binary (gomobile) built with
'go get' is not currently possible. What we can do instead is to check
if the current mobile repository found from GOPATH builds the same
binary by running 'go install -x -n' and checking if it outputs any
output. If so, this command prints out the revision info of the
repository. Otherwise, prints 'unknown'.
Sample output:
./gomobile version
gomobile version +27329c5 Wed Jul 22 19:29:08 2015 -0400 (android,ios);
androidSDK=/Users/hakim/Library/Android/sdk/platforms/android-22
./gomobile version
gomobile version unknown
Change-Id: Idc26c8a1dd3b43cc47a5c15ce130e2b97a460cec
Reviewed-on: https://go-review.googlesource.com/12455
Reviewed-by: David Crawshaw <crawshaw@golang.org>
iOS builds have been broken due to missing main executable. Xcode
doesn't complain and buildling the target .app bundle even if a
referenced objects doesn't exist.
Fixing .app builds and adding a unit test.
Change-Id: Ie9aec6c8c982a96c10bf07344e44bd501fcabd19
Reviewed-on: https://go-review.googlesource.com/12492
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If the application main package is in
golang.org/x/mobile/example/basic
the generated application will have "Basic" as its name.
Change-Id: Ic59fae6e18c26e406ab352265aa2d6b11619c102
Reviewed-on: https://go-review.googlesource.com/12435
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Tested manually, I can bind github.com/hyangah/ivy and include it
in an Xcode project.
Change-Id: I7dfa7828da7288841bc930d3e506ee97bf2ca520
Reviewed-on: https://go-review.googlesource.com/12388
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Tested:
go test golang.org/x/mobile/bind/java
gomobile bind -target={ios,android} github.com/hyangah/ivy
gobuild build -target={ios,android} golang.org/x/mobile/example/basic
(With various takes on -x and -v.)
Change-Id: I15c8f605490381feb6fefb482110f2a1c210529d
Reviewed-on: https://go-review.googlesource.com/12411
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Allows the use of -X, and similar flags.
Fixesgolang/go#11645.
Change-Id: I0ca097059f5f70c277c79eb89f2cbb10890db802
Reviewed-on: https://go-review.googlesource.com/12333
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The go command now has a -pkgdir flag, which specifies a directory
for all install output, including the standard library. Use it to
build the mobile compilers under $GOMOBILE, so that targets like
the iOS simulator (darwin/386) do not conflict with system targets.
The result is we no longer need GOROOT to be writable.
The iOS simulator now works with gomobile bind.
Fixesgolang/go#11342.
Change-Id: I0bc6378e0cb82e3175b2a1efe355e3ce39533649
Reviewed-on: https://go-review.googlesource.com/12303
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
First pass at bind support, simply produces .a/.h files.
In future CLs:
- Take the type defintion from seq.h and place it directly in the
generated header, breaking the user's dependency on seq.h.
Open question for future CLs:
- Should we create a framework directory?
If we bundle assets in the directory, can the asset package
find them automatically?
In 1.6: support multiple archives.
Change-Id: I7c3f655e7653018333e3ce3c89807edfcf62906d
Reviewed-on: https://go-review.googlesource.com/12199
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Now that we no longer modify the user's $GOROOT and run make.bash,
the need for isolating the environment is gone. Pass through
whatever users want, overriding only those necesssary for corss
compilation.
While here, remove some dead code.
Fixesgolang/go#11672.
Change-Id: Iaf867913eaa1311519a4d5a7a8169228ebf21346
Reviewed-on: https://go-review.googlesource.com/12128
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Note that darwin/386 is no longer released by the Android NDK.
Change-Id: Ie9d5105884db45a10716637980e8352c855293a0
Reviewed-on: https://go-review.googlesource.com/12121
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Subclassing NativeActivity makes two things possible. Firstly, we can
implement an InputConnection to offer good support for IMEs,
necessary for good keyboard support. Secondly, we can use it to
overlay WebViews onto the NativeActivity.
But to sublcass NativeActivity, we need to compile Java. To keep the
toolchain go gettable, this is done with go generate.
While here, check the exception after FindClass. Apparently it can
throw an exception.
Updates golang/go#9361.
Updates golang/go#10247.
Change-Id: I672545997f0c9a7580f06988a273c03404772247
Reviewed-on: https://go-review.googlesource.com/11980
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The goal here is to remove several inconsistencies between
-target=android and -target=ios support, along with making the flow
of the command follow the path you might expect given a certain set
of flags, and preparing for `gomobile bind` support of ios. In
particular, building non-main packages now works with both targets
and the initialization of global build state is clearer.
The reorg also is designed around an nm trick I thought of
yesterday to do better package import scanning without a slow
all-file scan. This will give better detection of x/mobile/app and
x/mobile/exp/audio/al packages. There's a TODO about it, and I'll do
it in a future CL.
Tested with:
go test golang.org/x/mobile/cmd/gomobile
gomobile init
gomobile bind golang.org/x/mobile/asset
go test golang.org/x/mobile/bind/java
gomobile build -target=ios golang.org/x/mobile/example/basic
gomobile build -target=ios golang.org/x/mobile/gl
gomobile build -target=android golang.org/x/mobile/gl
gomobile build -target=android golang.org/x/mobile/example/basic
(Along with manual testing of basic on an android device.)
That might make a pretty good _test.go.
Change-Id: I41230008c3c15db25a11c33b9eaca4abada9f411
Reviewed-on: https://go-review.googlesource.com/12051
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
In order to keep consistency with target=android, this CL turns
off gomobile build support for target=ios for programs that don't
import golang.org/x/mobile/app.
Change-Id: I423b042144aecfdc127726d0b97733c4d6532a81
Reviewed-on: https://go-review.googlesource.com/11985
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also point users towards gomobile bind and move the type restrictions
section to emphasis the code examples.
Change-Id: I57c867dce02a8d9fa12df7deab892b2705bf10fe
Reviewed-on: https://go-review.googlesource.com/11963
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The Go toolchain used to require that we rebuild the compiler and
friends (the cgo command) when building a cgo-enabled cross compiler.
This meant that gomobile init used to invoke make.bash in a temporary
copy of the GOROOT. This works, but brings with it several
complications, including needing to use -toolexec when invoking the
go tool, finding a boostrap copy of Go 1.4, long initialization
times, and a variety of unusual failure modes.
Fortunately we don't need our own compiler any more. All that's
necessary is building the standard library for the cross-compilation
targets and making sure the right C compiler is used when calling
go build (as it always was). This means most of the initialization
process can be replaced with a carefully invoked 'go install std'.
While here, remove the source install instructions (most of it is
documented already, and the final step, choosing the right git
revision should be within the skills of anyone using pre-release
software.) Some other documentation is changing because it's been a
while since go generate was run.
Change-Id: I88c10fef87867536e83c7df063ae7241b2e9eea4
Reviewed-on: https://go-review.googlesource.com/11711
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL adds iOS build support to gomobile command.
$ gomobile build golang.org/x/mobile/example/basic
gomobile builds an .app file that is signed with the development
provisioning entities.
You may deploy .app files to your test device or convert them to IPA
to publish on App Store or share them as an AdHoc distribution.
target=ios flag requires a Darwin host machine.
Fixesgolang/go#11043.
Change-Id: Ibc23b6d355f10b09940b20c813eb73d0f4313851
Reviewed-on: https://go-review.googlesource.com/11587
Reviewed-by: David Crawshaw <crawshaw@golang.org>
We are determining whether to add libopenal.so dependending on the
al package imports. The names must suggest we are looking for the
al package rather than the audio.
Change-Id: Ib6896302238ff1ebe135f004b134911a0c340821
Reviewed-on: https://go-review.googlesource.com/11680
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Historically, the app package implemented Go runtime initialization.
This was convoluted, so the package was used both by all-Go apps
(currently based on Android's NativeActivity) and bind-based apps.
With Go 1.5 we have -buildmode=c-shared, which does a lot of the work
of the old app package. That code was removed a while back, but both
all-Go and gobind-based apps still used package app. The intermingled
initialization processes led to some strange states.
This CL separates gobind-based apps completely from the app package.
As part of that users are now expected to use System.loadLibrary
themselves. (A future CL may want to make the loadLibrary call part
of the .aar generated by gomobile bind.)
Delete the libhello example, which has been replaced by gomobile bind,
which could do with its own example at some point. Also delete the
libhellojni example, which now has nothing to do with the x/mobile
repository.
Change-Id: I444397f246dbafe81e5c53532eb482c197d26f70
Reviewed-on: https://go-review.googlesource.com/11654
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
An app could conceivably import the former without importing the latter.
Change-Id: I7b0e13fe7d9e6d9e586fa2edf00811330be2a9b7
Reviewed-on: https://go-review.googlesource.com/11607
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This reverts commit 597df59d36d6b5a9e4bfec918053495d750fa2dd.
Reverting the change since, runtime/cgo is still not buildable and CCFLAGS is not a valid env variable. See golang/go#11339 for more information.
Change-Id: I2f168508d1ca72f5c75ff641938fd3b304939617
Reviewed-on: https://go-review.googlesource.com/11453
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
