This repository has been archived by the owner on May 9, 2022. It is now read-only.
CI build mobile libs #21
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Robert-Steiner
force-pushed
the
ffi-ci
branch
2 times, most recently
from
de46fcc to
86e5703
Compare
janpetschexain
force-pushed
the
ffi-ci
branch
2 times, most recently
from
ebded9c to
f63e059
Compare
acrrd
reviewed
Mar 18, 2021
janpetschexain
force-pushed
the
ffi-ci
branch
3 times, most recently
from
bbbe556 to
3514dd4
Compare
|
your pr summary is awesome 👍 we should put a link to this readme/pr directly in the ci yaml file. |
Thanks 😊. I can do that! |
janpetschexain
force-pushed
the
ffi-ci
branch
3 times, most recently
from
ed08f13 to
85d6a2a
Compare
acrrd
approved these changes
Apr 7, 2021
Co-authored-by: janpetschexain <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal:
We want to test our android/ios libraries on different cpu architectures
in order to identify errors early in development.
What we have achieved:
We can compile and test our android libraries on different cpu architectures by using an emulator.
However, we can only compile the iOS libraries because there is no emulator for it.
We could run our tests on the iOS simulator, but it uses an architecture (x86_64)
which is not used in any iOS device. So it is not worth it.
Implementation details
Use a build matrix for testing/building android/ios libraries on different cpu architectures
There are several advantages to using a build matrix instead of one job that builds/tests all of the libraries one at a time:
Optimised android test
We noticed that the execution time of the tests on the emulator is significantly reduced
if we compile our tests in
releasemode. However, in release mode thedebug assertionsare removedwhich means that we lose some checks. So the idea was to compile it in debug mode (to keep the
debug assertions) and only setopt-levelto3(to turn on all optimisations).However, this turned out to be more difficult than expected. In the end we decided to use
RUSTFLAGS="-C opt-level=3 -C debug-assertions=yes". More details at the end of the description.test-android-libs without caching / debug mode
17m 25s59m 5stest-android-libs without caching / release mode
11m 32s37m 44stest-android-libs with caching / release mode
4m 38s13m 7sWe have activated the option
-- -Z unstable-options --report-timeso that if a test suddenly becomes slow again, we can recognize it immediately.Using
crossfor testingcrossmakes it easy to test our code on different cpu architectures. Under the hood it runs a docker container that runs an emulator (qemu).Features/Limitations of
crosscrossmounts the repo into the container, you cannot execute it in a folder belonging to a member who depends on another memberFor example:
does not work. It cannot find the directory of
rubert, since it is not mounted into the container. So you have to runUsing
cargo-ndkfor building the release binariesTo build the final android libraries we will keep using
cargo-ndkbecause it has some advantages overcross:ndkwe can set the ndk api level (incrossit is hardcoded in the dockerfile)ndkautomaticallystrips the binary (with the right strip binary) + moves it into thejniLibfolder structureWe will do the integration of
cargo-ndkin a separate pr.Why we chose
RUSTFLAGSinstead of[profile.test]TL;DR:
The test profile only applies to our library but not on the dependencies.
cargo book
cargo testDependencies
If
opt-levelis missing the compiler will by default use-C opt-level=0which implies
-C debug-assertions=onOur Library
default:
-C opt-level=0->-C debug-assertions=oncargo test&Dependencies
-C opt-level=3impliesdebug-assertions=offbut cargo correctly uses the default value ofdebug-assertions=oninprofile.dev.Our Library
cargo test&Dependencies
Our Library
Cool, we've reached our goal, haven't we? Not really.
If we add
opt-level=3toprofile.dev, the complication times during localdevelopment will be longer.
An alternative would be to use
RUSTFLAGS. Let's take a look.RUSTFLAGS="-C opt-level=3" cargo testDependencies
Our Library
Hmmm cargo does not apply the default values of the profiles anymore.
What happens if we and
profile.devagain?RUSTFLAGS="-C opt-level=3" cargo test&Dependencies
debug-assertions=onis back and we haveopt-level=3twice.Which of the two
opt-level=3will it actually choose?Our Library
Let's set
opt-levelto3in theCargo.tomland call cargo withRUSTFLAGS="-C debug-assertions=no".RUSTFLAGS="-C debug-assertions=no" cargo test&Dependencies
The test did not fail, so the
debug-assertionsare turned off which means that the lastdebug-assertionsflag overwrites the previous flag.In order to have both
opt-level=3anddebug-assertions=yeswe need to runRUSTFLAGS="-C opt-level=3 -C debug-assertions=yes" cargo testDependencies
Our Library