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

x/mobile/app/ivy/android: no documentation #23285

Open
seebs opened this issue Dec 29, 2017 · 1 comment

Comments

@seebs
Copy link
Contributor

commented Dec 29, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.9.2

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

x86_64 linux

What did you do?

Try to build app, guessing at instructions from various sources and comments on other issues.

What did you expect to see?

A way to build the app.

What did you see instead?

Lots of partial instructions which, if followed, produce diverse and fascinating errors and diagnostics for things I probably did wrong.

So, basically what I'm looking for is a README.md parallel to ivy/ios/README.md, which says things like:

"Place the mobile.framework directory in this directory, and
then open ivy.xcodeproj in Xcode."

I guessed that following parallel instructions (gomobile bind -target=android robpike.io/ivy/mobile) would produce... something? and i got a "mobile.aar" and "mobile-sources.jar". But where should they go? I tried putting them in "this" directory (ivy/android), and gradlew build eventually fails with:

:ivy:gobind FAILED

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ':ivy:gobind'.

Cannot get property 'classpath' on null object

Further experimentation has not gotten me anywhere, and I don't have enough experience with the various tools to guess where to look. A simple "follow these steps and an apk should result" would be super helpful. Frustratingly, none of --stacktrace, --info, or --debug seems to give me the information that I would have thought would be most useful, which is "what actual executable was running, with what arguments, that produced that message?" Because being able to narrow that down might help me spot something like "the path it's looking in for a thing".

@gopherbot gopherbot added this to the Unreleased milestone Dec 29, 2017

@seebs

This comment has been minimized.

Copy link
Contributor Author

commented Dec 29, 2017

Update: The actual build problem appears to be #21594, apart from that the iOS instructions are in fact close enough to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.