Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/mobile/cmd/gomobile: gomobile bind generates binding code on every execution #12819

Closed
sridharv opened this issue Oct 2, 2015 · 10 comments
Closed

x/mobile/cmd/gomobile: gomobile bind generates binding code on every execution #12819

sridharv opened this issue Oct 2, 2015 · 10 comments
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Milestone
Unreleased

Comments

@sridharv
Copy link

sridharv commented Oct 2, 2015

This can't really be called a bug, but it is potentially sub-par behaviour. It is a follow on from a suggestion I made in #12245.

gomobile bind currently generates binding code every time it is run. This has the following side effects:

  • Access to source for debugging: When debugging application errors in the wild, it is useful to have the source available. In the case of native libraries, we can use vendoring or the native package manager for versioning. With gobind however, the source is not easily available. It can be generated by manually running gobind, but there are a few concerns with this approach.
    • The options passed to gobind are opaque to the user: Currently there are no options, but if this changes in the future it becomes a guessing game.
    • Upgrades of the gobind tool can result in source changes: For production releases we will need to track the exact version of gomobile used to generate the library. This is fine once gobind is stable (for example with cgo now). However, it is problematic for early adopters since changes are being made to gobind on a regular basis.
  • Incremental builds: In an SDK app, gomobile bind must be run on source changes to regenerate the new framework/aar. There are two ways of approaching this. Manually run gomobile bind or have the IDE (XCode/Android Studio) invoke it before compiling the ObjC/Java source. The former, while not a chore, can be error prone. The latter is more robust, but results in the framework/aar being rebuilt even if no go source is changed. This adds delays to the code -> compile -> test cycle and negatively impacts our workflow. It also takes away one of the advantages of go which are its near instantaneous build times.

One solution would be for gomobile bind to accept a command line flag which specifies the directory in which to generate code and then skip regenerating code on every run.

This is more a nice to have rather than a need to have since there are workarounds present.
@sridharv sridharv mentioned this issue Oct 2, 2015
Closed
@rakyll rakyll added this to the Unreleased milestone Oct 2, 2015
@rakyll
Copy link
Contributor

rakyll commented Oct 2, 2015

/cc @hyangah

@jeffallen
Copy link
Contributor

Yes please. My Android Studio build times went from 2 secs to 10 secs by adding a Go module to my project. For a language with a reputation for fast build times, it's beyond ironic and really unfortunate that Go is making Java builds slower!

@crawshaw
Copy link
Member

crawshaw commented Nov 2, 2015

Hana and I discussed this last week. We decided to experiment with putting the generated .java files into the .aar. Then gomobile bind can compare a hash of the newly generated .java against the old, and only touch the .aar if either the .java has changed, or the generated .so would have changed.

This avoids adding a flag for a working directory, which I consider important as keeping and reusing intermediate data introduces a new way you can get incorrect builds.

@hyangah hyangah mentioned this issue Nov 5, 2015
Closed
@sridharv
Copy link
Author

sridharv commented Nov 8, 2015

Thank You! In addition, please keep in mind the fact that a large number (and most likely the majority) of mobile apps are closed source. Shipping production builds with source files might be problematic for many people. However, this can be worked-around by repackaging the final aars manually.

@eliasnaur
Copy link
Contributor

gomobile bind also generates .so files for every architecture (currenty arm, x86 and x86_64 and possible arm64 in the future). Would it make sense to make an option to gomobile (and the gradle plugin) to limit the architectures, for example to arm, arm64? Alternatively, an environment option so the architecture set can be changed for debug and release. I rarely use the emulators anyway.

@hyangah
Copy link
Contributor

hyangah commented Mar 7, 2016

Try --target=android/386 etc

The gradle plugin should be updated though.

On Mon, Mar 7, 2016 at 8:18 AM, eliasnaur notifications@github.com wrote:

gomobile bind also generates .so files for every architecture (currenty
arm, x86 and x86_64 and possible arm64 in the future). Would it make sense
to make an option to gomobile (and the gradle plugin) to limit the
architectures, for example to arm, arm64? Alternatively, an environment
option so the architecture set can be changed for debug and release. I
rarely use the emulators anyway.

—
Reply to this email directly or view it on GitHub
#12819 (comment).

__

@eliasnaur
Copy link
Contributor

Of course, thanks. I'll look into updating the gradle plugin if noone beats
me to it.

On Mon, Mar 7, 2016 at 2:43 PM Hyang-Ah Hana Kim notifications@github.com
wrote:

Try --target=android/386 etc

The gradle plugin should be updated though.

On Mon, Mar 7, 2016 at 8:18 AM, eliasnaur notifications@github.com
wrote:

gomobile bind also generates .so files for every architecture (currenty
arm, x86 and x86_64 and possible arm64 in the future). Would it make
sense
to make an option to gomobile (and the gradle plugin) to limit the
architectures, for example to arm, arm64? Alternatively, an environment
option so the architecture set can be changed for debug and release. I
rarely use the emulators anyway.

—
Reply to this email directly or view it on GitHub
#12819 (comment).

__

—
Reply to this email directly or view it on GitHub
#12819 (comment).

@gopherbot
Copy link

CL https://golang.org/cl/20305 mentions this issue.

gopherbot pushed a commit to golang/mobile that referenced this issue Mar 7, 2016
modbile/misc/androidstudio: add GOARCH to the gradle plugin
493d0b4 
Add GOARCH to the gobind gradle plugin to limit the architectures to
include in the fat .aar file. If GOARCH is empty or not specified,
every supported architecture is included.

GobindPlugin.groovy was indented with both tabs and (a varying number
of) spaces, so it is re-indented here with tabs. Sorry.

For golang/go#12819

Change-Id: I8b2cb72068df7750d20f474395944ca2968a2f1b
Reviewed-on: https://go-review.googlesource.com/20305
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@gopherbot
Copy link

CL https://golang.org/cl/20331 mentions this issue.

gopherbot pushed a commit to golang/mobile that referenced this issue Mar 8, 2016
@hyangah
misc/androidstudio: release gobind gradle plugin 0.2.4
2e1e39e 
That supports GOARCH property.

Also this CL updates examples and upgrades the android gradle plugin
used in examples (from 1.2.3 to 1.5.0)

For golang/go#12819

Change-Id: Ibfed128eaf725775810aa539bd5c0e1ca88f1b85
Reviewed-on: https://go-review.googlesource.com/20331
Reviewed-by: David Crawshaw <crawshaw@golang.org>
@gopherbot gopherbot added the mobile Android, iOS, and x/mobile label Jul 20, 2017
@eliasnaur
Copy link
Contributor

I believe this is fixed by https://go-review.googlesource.com/99316. You can now use the gobind tool to generate a complete set of bindings. The gomobile tool calls gobind so you're guaranteed that the output from gobind is what gomobile uses.

@golang golang locked and limited conversation to collaborators Mar 16, 2019
@rsc rsc unassigned hyangah Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
7 participants
@rakyll @crawshaw @sridharv @eliasnaur @jeffallen @hyangah @gopherbot