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

na-mainloop: Drop unneeded cargo-apk setup and add xbuild docs #9

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

MarijnS95
Copy link
Member

Without configuration cargo-apk uses the default rust.<package> namespace, instead of the hardcoded com.foo.bar. Similarly xbuild can build and run this project out of the box, no extra configuration (nor installation / dependencies!) required.

Draft because it seems we have a lot more projects to clean up, and maybe even guides to deduplicate...

@MarijnS95 MarijnS95 force-pushed the cargo-apk-cleanup-and-xbuild branch 3 times, most recently from ac61f12 to 5e30ef6 Compare June 26, 2023 20:29
@rib
Copy link
Contributor

rib commented Jun 27, 2023

Yeah this sounds probably ok if they can Just Work(tm) - maybe the gradle builds could be configured with the same application Id that cargo apk / xbuild will come up with by default. Does xbuild have the same default as cargo apk here?

Btw, it would be kinda interesting to know if it would be possible to have xbuild also work with the agdk examples at some point, and those would need some kind of config for knowing to fetch the game-activity dependency.

@MarijnS95
Copy link
Member Author

Does xbuild have the same default as cargo apk here?

Afaik they're different.

@MarijnS95
Copy link
Member Author

Btw, it would be kinda interesting to know if it would be possible to have xbuild also work with the agdk examples at some point, and those would need some kind of config for knowing to fetch the game-activity dependency.

xbuild has gradle support, but I've never toyed with it. Would be lovely if you could!

@MarijnS95
Copy link
Member Author

@rib
Copy link
Contributor

rib commented Jun 27, 2023

xbuild has gradle support, but I've never toyed with it. Would be lovely if you could!

I don't really know where to start with configuring xbuild without looking at the implementation atm, the README doesn't show any examples and I haven't seen it reference any example projects. Can you maybe link to some open source example with an xbuild config to get a starting point for knowing what's configurable?

@MarijnS95
Copy link
Member Author

Maybe @dvc94ch has a link. Afaik it's "as simple as" setting gradle: true under android: in manifest.yaml, at least that's what's being done for the template.

Supposedly it creates a bunch of files in the source dir for you, at least if mod.rs is believed:

https://github.com/rust-mobile/xbuild/tree/master/xbuild/src/gradle

@MarijnS95 MarijnS95 force-pushed the cargo-apk-cleanup-and-xbuild branch 2 times, most recently from e5251b5 to 8d7cb4a Compare July 18, 2023 20:07
Without configuration `cargo-apk` uses the default `rust.<package>`
namespace, instead of the hardcoded `com.foo.bar`.  Similarly `xbuild`
can build and run this project out of the box, no extra configuration
(nor installation / dependencies!) required.
@MarijnS95 MarijnS95 force-pushed the cargo-apk-cleanup-and-xbuild branch from 8d7cb4a to e95e9c4 Compare July 18, 2023 20:08
@MarijnS95
Copy link
Member Author

Well this is awkward. The Ubuntu VM probably has a weird/old clang/LLVM setup as I cannot repro this issue locally, though xbuild itself uses a very similar CI setup to do build-testing.

@MarijnS95
Copy link
Member Author

MarijnS95 commented Jul 24, 2023

I just ran into this myself while trying to teach xbuild to support env vars with spaces.

xbuild sets CARGO_TARGET_<triple>_RUSTFLAGS, and that probably gets skipped/ignored because the CI script already sets RUSTFLAGS, hence it's using the wrong compiler flags.

Its precedence is not documented at https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags, but it probably falls at position 3. (after RUSTFLAGS which is at 2.) as it is supposed to provide a value for target.<triple>.rustflags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants