-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
x/mobile: binding doens't seem to reuse build cache for modules #37902
Comments
CC @hyangah |
The temporary directory is created in the following line: https://github.com/golang/mobile/blob/0df4eb2385467a487d418c6358313e9e838256ae/cmd/gomobile/env.go#L61 |
The solution mentioned by @MariusVanDerWijden seems to work. Is this going to be added anytime soon? |
My understanding is that Go's build cache is created somewhere, wherever you build your application. Then the temporary directory should not matter. Is that correct? I believe If so, is the culprit building Java or C files? |
@karalabe I'm sorry for the delay. Is this problem happening in Android or iOS, or both? |
Hi @hajimehoshi I'm having the same issue here. Indeed, I specify the workdir using the flag |
Any chance we can get the solution in https://go-review.googlesource.com/c/mobile/+/273406 merged? PR on Github: golang/mobile#58 (though the discussion is on googlesource) |
you can try this : |
This is not related to the cache, but I hope https://go-review.googlesource.com/c/mobile/+/426274 would mitigate the slowness of Android building. I'll try iOS later. |
@modasi What change did you add to gomobile? EDIT: I think this is it (initializing if buildN {
tmpdir = "$WORK"
cleanupFn = func() {}
} else if buildWork {
tmpdir = "/tmp/gomobilework"
fmt.Fprintln(xout, "WORK="+tmpdir)
} else {
tmpdir, err = ioutil.TempDir("", "gomobile-work-")
if err != nil {
return nil, err
}
} |
Did this issue exist before Go modules support was introduced? If not, I was wondering how supporting Go modules triggerred this... |
Change https://go.dev/cl/442195 mentions this issue: |
This change makes building archive files for iOS concurrent for each architecture and each platform. The strategy is basically the same as my previous CL for Android: https://go.dev/cl/426274. This change also specifies GOMODCACHE explicitly when executing Go commands so that the existing cache is always used. The default GOMODCACHE is $GOPATH/pkg/mod, and this path varies when a temporary GOPATH is specified, which results in cold cache. Before this change (on my MacBook Pro 2020): $ time go run ./cmd/gomobile/ bind -target ios ./example/bind/hello/ real 0m23.274s user 0m15.751s sys 0m10.469s After this change: $ time go run ./cmd/gomobile/ bind -target ios ./example/bind/hello/ real 0m8.059s user 0m13.763s sys 0m9.004s Updates golang/go#37902 Updates golang/go#54770 Change-Id: Iaeb077b58c22ab63d28f78972a0af76660883a05 Reviewed-on: https://go-review.googlesource.com/c/mobile/+/442195 Reviewed-by: Changkun Ou <[email protected]> Run-TryBot: Hajime Hoshi <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Hyang-Ah Hana Kim <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Can anyone test the latest gomobile? |
Let me close this. Feel free to reopen this when you find this unresolved. |
Apologies for not adhering to the default issue template, the issue is not a "bug" per se and not an issue with Go itself, so all those version and env infos would be useless.
gomobile
added module support recently, which works spectacularly. One thing, however, that I did notice, is that if I callgomobile bind
on a package that has heavy dependencies, those get rebuilt from scratch for every build, making the build very painful.E.g. Binding https://github.com/coronanet/go-coronanet will take 30 mins as it needs to build a dependent package that contains a huge C library (Tor). However, trying to call bind again with zero modifications will again take 30 mins. This is in contrast with building simply with Go locally, which will take 5 mins for the first run, but will be ~instantaneous afterwards (only link time is left).
My best guess until now is that
gomobile bind
creates its own temporary working directory/tmp/gomobile-work-xxxxxxxx
and thus all code operations are short circuited into that folder, away from the system caches. This results in all object files produced by one build run to be deleted at the end.Issue opened per @hajimehoshi 's request in #27234 (comment).
Continuing a thread from the above issue:
No, I'm not referring to caching the generated files, rather the module dependencies of them, which should most definitely be cacheable.
The text was updated successfully, but these errors were encountered: