As previously established xbuild really likes to run on a development machine where tools like adb and LLVM/clang are provided by the host (already installed).
This is easier to expect or satisfy on Linux machines than Windows, where setup takes many more steps. Especially if the developer experience is tailored around Rust which requires nothing more than rustup. Our desire is to have xbuild work similarly out-of-the-box after a cargo install xbuild, and we're already half the way there by no longer having to install and set up the env vars for the SDK/NDK/build-tools, nor require Java. Though adb and LLVM are still a point of contention.
The solution I'm eyeing is downloading and unpacking these similar to how the stripped NDK is handled currently.
As a long-term solution we'd like to leverage LLVM within the rustup toolchain but we're not there yet.
Another caveat is that usernames with spaces are not currently supported. X puts the unpacked stripped-down NDK somewhere within the home directory (in an appdata cache folder IIRC?), which requires --sysroot to be passed to the C(XX)FLAGS for cc-rs and they clearly state that spaces are not supported in here, not even with quotes, escape characters or the \x1f Unit Separator ASCII character as used in CARGO_ENCODED_RUSTFLAGS: https://github.com/rust-lang/cc-rs/#external-configuration-via-environment-variables.
This is implicitly not a problem in cargo-apk by not using a stripped-down NDK, because the compiler already lives at ./bin/clang next to ./sysroot which is automatically detected:
https://github.com/llvm/llvm-project/blob/d82f0b74dec133cb90767edb032f987930d53772/clang/lib/Driver/ToolChains/Linux.cpp#L373-L380
@dvc94ch (and maybe @rib) what are your thoughts on this? If we can reach an agreement I'd like to build this in such a way that it can be merged into the main xbuild repo, rather than living on our fork as we'll inevitably build this to solve our immediate need of having an out-of-the box experience without skewed host setups.
As previously established
xbuildreally likes to run on a development machine where tools likeadband LLVM/clangare provided by the host (already installed).This is easier to expect or satisfy on Linux machines than Windows, where setup takes many more steps. Especially if the developer experience is tailored around Rust which requires nothing more than
rustup. Our desire is to havexbuildwork similarly out-of-the-box after acargo install xbuild, and we're already half the way there by no longer having to install and set up the env vars for the SDK/NDK/build-tools, nor require Java. Thoughadband LLVM are still a point of contention.The solution I'm eyeing is downloading and unpacking these similar to how the stripped NDK is handled currently.
As a long-term solution we'd like to leverage LLVM within the
rustuptoolchain but we're not there yet.Another caveat is that usernames with spaces are not currently supported. X puts the unpacked stripped-down NDK somewhere within the home directory (in an appdata cache folder IIRC?), which requires
--sysrootto be passed to theC(XX)FLAGSforcc-rsand they clearly state that spaces are not supported in here, not even with quotes, escape characters or the\x1fUnit Separator ASCII character as used inCARGO_ENCODED_RUSTFLAGS: https://github.com/rust-lang/cc-rs/#external-configuration-via-environment-variables.This is implicitly not a problem in
cargo-apkby not using a stripped-down NDK, because the compiler already lives at./bin/clangnext to./sysrootwhich is automatically detected:https://github.com/llvm/llvm-project/blob/d82f0b74dec133cb90767edb032f987930d53772/clang/lib/Driver/ToolChains/Linux.cpp#L373-L380
@dvc94ch (and maybe @rib) what are your thoughts on this? If we can reach an agreement I'd like to build this in such a way that it can be merged into the main
xbuildrepo, rather than living on our fork as we'll inevitably build this to solve our immediate need of having an out-of-the box experience without skewed host setups.