proposal: x/mobile/cmd/gomobile: define a build tag to distinguish gomobile-bind and gomobile-build #24490
Labels
Milestone
Comments
bcmills
changed the title
|
@eliasnaur, thoughts? |
|
Perhaps build tags are the answer, but I'd like to know a bit more about your use case first. What is the purpose of a library that is both bindable and buildable? Bind is for producing a Go library to use from native code, while build is for producing a complete program ready to run. In regular Go, you would have the library part in some package A (gomobile bind), and then have a different package main that imports and uses A (gomobile build). Then, why can't you import golang.org/x/mobile/app in bind mode? |
In my use case, I have a game lib containing a main loop for desktop usages, and a package for gomobile-bind that uses the game lib. From the mobile, the game lib doesn't activate the mail loop. Now I wanted to make the game lib accept gomobile-build, and encounters the problem that gomobile-build require golang.org/x/mobile/app and gomobile-bind not. Well, splitting the game lib into two parts would work: one includes the main loop and the other not. It's possible, but that would require a big code change.
I thought this caused a runtime error, but let me double-check. |
diff --git a/internal/ui/mainloop_gomobilebuild.go b/internal/ui/mainloop_gomobilebuild.go
index afeba8fc..1de50304 100644
--- a/internal/ui/mainloop_gomobilebuild.go
+++ b/internal/ui/mainloop_gomobilebuild.go
@@ -13,7 +13,7 @@
// limitations under the License.
// +build android ios
-// +build gomobilebuild
+//// +build gomobilebuild
package ui
diff --git a/internal/ui/mainloop_notgomobilebuild.go b/internal/ui/mainloop_notgomobilebuild.go
index e258f013..2e9e9d55 100644
--- a/internal/ui/mainloop_notgomobilebuild.go
+++ b/internal/ui/mainloop_notgomobilebuild.go
@@ -14,6 +14,7 @@
// +build android ios
// +build !gomobilebuild
+// +build ignore
package ui
|
|
Change https://golang.org/cl/104395 mentions this issue: |
|
Does http://golang.org/cl/104395 help? And since I sometimes miss the obvious: have you tried the -tags flag? It should work for both gomobile bind and gomobile build. |
Ah yes, if that CL avoid unnecessary loading Java class for gomobile-bind, I think this would solve the problem, and I'd not need the build tag to distinguish bind and build.
Yes, |
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 10, 2021
Delay loading of the getRune method ID to the first GoNativeActivity is created. That way, importing golang.org/x/mobile/app will not crash, even for gomobile bind programs that don't include (or use) GoNativeActivity. Fixes golang/go#24490 Change-Id: I4bf90e067700451f7c026e53165b6614366d7a94 Reviewed-on: https://go-review.googlesource.com/104395 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 11, 2021
Delay loading of the getRune method ID to the first GoNativeActivity is created. That way, importing golang.org/x/mobile/app will not crash, even for gomobile bind programs that don't include (or use) GoNativeActivity. Fixes golang/go#24490 Change-Id: I4bf90e067700451f7c026e53165b6614366d7a94 Reviewed-on: https://go-review.googlesource.com/104395 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm trying to build a library that can run both on gomobile-bind and gomobile-build. Importing
"golang.org/x/mobile/app"must be present for gomobile-build, while it must not be present for gomobile-bind. Thus, I'd need to separate some compiled files: some for gomobile-bind and the others for gomobile-build. If there'd be a build tag to distinguish them, it'd be very useful.The text was updated successfully, but these errors were encountered: