.so does not end up in .apk if project inside workspace
lattice0 opened this issue · comments
If you have
android_project
libsomething
libsomething2
Cargo.toml
and Cargo.toml
happens to be a workspace for libsomething
and libsomething2
, then
cargo {
module = "../../../libsomething"
libname = "something"
verbose = true
apiLevel = 21
profile = 'release'
targets = ["arm64"]
}
will compile the libs but the libsomething.so
does not end up in the rustJniLibs folder, probably because the target
folder is not inside libsomething
but at the root workspace.
I don't want to compile the entire workspace, just this lib, that's why I point to just it. If I pointed to the workspace, it would probably work, but the workspace contains non android things.
Fully working example: https://github.com/lattice0/flutter_workspace/blob/master/flutter_bug/android/app/build.gradle#L66
What could be done here? I really need this stuff to be in a workspace otherwise rust-analyzer
goes completely crazy.
Use targetIncludes
. I'm going to leave this open because I'm not confident that targetIncludes
will work with relative paths, although I expect it will. Please report back if you can't solve this with targetIncludes
; we can probably make it handle absolute and relative paths easily enough.
Unfortunately it doesn't work. I also tried to pass
cargo {
module = "../../../"
libname = "something"
so it builds the workspace but only uses something
, but in this case libsomething2
cannot even be built because it's not for android (it's not even a lib, but a desktop application).
I think the best option here would be to run cargo run --package=${libname}
. Then it would always compile the workspace but just the libname
I think the best option here would be to run
cargo run --package=${libname}
. Then it would always compile the workspace but just the libname
I assume you mean cargo build --package=...
. I'd take a patch to do that, or at least I'd get it tested in CI and review it. I will say that historically workspaces plus specific --package=...
invocations straight up didn't work, but that was years ago so the situation may be much better. Working code will win out :)
I was able to make it work by
targetDirectory = '../../../target'
I tried to fix the problem though but gradle is very annoying when using a local plugin for fast changes
I was able to make it work by
targetDirectory = '../../../target'
I tried to fix the problem though but gradle is very annoying when using a local plugin for fast changes
Can you say more? The substitution workflow is pretty smooth for me: https://github.com/mozilla/rust-android-gradle/blob/master/README.md#testing-local-changes.
I had similar issues and I can confirm that a mix of:
targetIncludes = ["my_library.so"]
targetDirectory = "../path/to/target/"
Fixed it for me. Thank you both for the workaround!
I had similar issues and I can confirm that a mix of:
targetIncludes = ["my_library.so"] targetDirectory = "../path/to/target/"
Fixed it for me. Thank you both for the workaround!
Glad to hear it. @lattice0, if you want to propose a "first class" fix, I'd entertain it.
same problem here. I cant get it to work with any combination of targetIncludes
and targetDirectory
Ignore my previous comments - I was looking for jniLibs
folder when the plugin puts them in rustJniLibs
. Also they arent visible in android studio. I had to look in the android//build folder folder