It seems like shared library terminology has left as a legacy
from the days bind command only supported Android and bind was
generating shared libraries as an output.
Additionally, rewording the mention of apks and apps.
These libraries aren't generated for apk or apps but Android IDE
or Xcode projects.
Change-Id: I46dd56ddccde2d2526fa9b69f700c48c5dd474db
Reviewed-on: https://go-review.googlesource.com/14039
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
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>
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>
Change-Id: Ie7bd43cdf8d759e6d739824c59cac0e01d1a4b95
Reviewed-on: https://go-review.googlesource.com/9630
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: I2a41cf0f16dcefe87c73ab0a8f02a251c1243157
Reviewed-on: https://go-review.googlesource.com/8121
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
