Itās exactly what Iām talking about. Is there reason you canāt just download them within build process?
GitHub have 1GB soft limit and your repo already 168MB and itās just bad practice to store binaries in git.
So would be better if Travis would just download them from our server (if there no other way to get them) during build process. Then we can rewrite repository history with rebase so itās wonāt be 160MB.
If you can implement it to generate package with name like that itās would be great:
Yeah, SDL addons would need to be either hosted somewhere and downloaded during build or mirrored on github and added as submodules.
Other than that, ā./build.py fixpaths build-optionalā should build all of the non-cmake libs.
I added them to repo because it makes building the project much simpler/quicker and these libs donāt really need to be ever rebuilt unless we upgrade lib versions.
Keep in mind that ffmpeg takes quite a long time to build (around 20 mins per arch on my pc) + it needs to be checked if travis machines can handle asm out of the box (yasm).
Yep I understand why you added them to the when you tried to get it work. This is just something that need to be changed and if there are no āready to useā binaries available in trusted source then we can just host our own, but certainly not on git.
If you can please generate SSH key and send me public part so I can provide you with SFTP access to special server where youāll able to upload all dependencies needed.
Current repo version of launcher should create output apks with name [travis_job_id]-[launcher_git_sha]-vcmi-[vcmi_branch]-[vcmi_git_sha]-debug].apk. ("-debug" only in debug builds, travis job id only if thereās such env variable, git-shas are first 7 chars).
Thanks. Is there any reason you want to stick to certain VCMI commit? Canāt you just build latest develop?
Asking since main reason to have Travis at all is to make sure we do not break building on Android.
Also I want Android builds to be generated and uploaded daily by Travis even when youāre away.
No. There was failed build because I made it output find of every file and Travis consider log over 4MB as failure. So other than ācommited byā itās looks fine and build passed.
Now I also fixed uploading, but we certainly need Release build instead of Debug.
Sadly itās still show horrible red screen on my deviceā¦
GeneratedVersion was just meant to hold current vcmi version + git sha, but it doesnāt update correctly (itās generated in cmake script and cmake sometimes uses cache instead of rerunning it ā I guess I could move it to gradle script since I added git sha checking there anyway).
Well, yeah. It always is confusing and usually I break stuff when rebasing.
I think I should add some dedicated āreleaseā singing keys to repo (either generate new ones or just reuse default androidās debug keys because it doesnāt really matter).
Well, yeah. It always is confusing and usually I break stuff when rebasing. :PItās even more confusing since I had to mess with reflog. Also I still have no idea how to make GitHub purge orphan originals. I suppose itās will remove them from reflog after default 2 week grace period, but weāll see.
If some signing itās the only difference in that case then I donāt care personally. I was worried ādebugā build going to have worse performance since itās might have some options disabled.
If you can please do. I still wish to attempt test of cross-platform multiplayer.
Debug does have worse performance and we should switch to release.
In debug mode gradle script automatically signs the package using āinternalā android debug keystore.
For release build gradle by default doesnāt sign the package and requires dev to specify āreleaseā keystore (like I did with actual release vcmi keys in github.com/vcmi/vcmi-android/bl ā¦ radle#L149 (keeping them out of repo of course)). For release mode build on travis we need to specify some signing keys, but these can be any keys, including android āinternalā keystore.
Yep in that case we certainly need release builds and obviously Iāll prefer to not expose signing keys even on our server.
Also I tested multiplayer itās works flawlessly. Though Android client crashed in Linux Host + MXE Windows guest + Android guest game, but I expect this could be result of fact how itās loaded some extra mods or something.
PS: I also enabled daily build for your repository by Travis and added notifications to Slack.
Now we can track if we break building on Android all the time.
I added possible fix for invalid colors here: github.com/Fayth/vcmi/blob/expe ā¦ T.cpp#L410 ). Iām not sure if you can somehow build it on your side or I should make a PR to develop?
I think I could just cherry-pick it, but would be handy if you can add some argument to Android build scripts that Travis trigger. So in future we can just create new branch in vcmi-android with modified Travis config and itās will make build for us.
E.g like:
# Now we have
python3.5 ./build.py build-app
# But we can do
python3.5 ./build.py build-app HEAD
python3.5 ./build.py build-app develop
python3.5 ./build.py build-app experimental/sdl-color-fix
OR even better. Expose that argumnent and Iāll implement travis script that let us trigger build by creating new branch in vcmi-andoid like:
buildForMe/feature/ambientSounds
And itās will build āfeature/ambientSoundsā branch from upstream.
Also in future we can just make Android builds on every commit / branch / PR just like we do for Linux GCC, Linux Clang, MXE and Mac. Sadly that would take time to implement and I have tons of other tasks on project right now.
Ok. For now itās set to only build āfa02900ā commit from develop.
Please make it always build develop HEAD and also get rid of āinternalData.zipā.