x/mobile/cmd/gomobile: remove gomobile stripped NDK #16211
Labels
Milestone
Comments
|
Is it too naive to attempt to build the openal libraries during gomobile init? |
|
that's what i am thinking as well but according to what's in cmd/gomobile/release.go, |
|
CL https://golang.org/cl/35173 mentions this issue. |
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 10, 2021
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. Fixes golang/go#16211 Fixes golang/go#18522 Change-Id: Ia38f6e43e671a207dad562678c65225b426e7e3e Reviewed-on: https://go-review.googlesource.com/35173 Reviewed-by: David Crawshaw <crawshaw@golang.org>
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 11, 2021
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. Fixes golang/go#16211 Fixes golang/go#18522 Change-Id: Ia38f6e43e671a207dad562678c65225b426e7e3e Reviewed-on: https://go-review.googlesource.com/35173 Reviewed-by: David Crawshaw <crawshaw@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
gomobile stripped NDKs created by release.go are still smaller than the android full NDK.
But
I propose to remove the need of stripped NDK.
Now gomobile can reuse cached NDKs, so I don't expect the tool to require users to download it for every init command.
Unclear issue is
what to do about open-AL tar file gomobile init also downloads?
@crawshaw @eliasnaur @rakyll
The text was updated successfully, but these errors were encountered: