Android TCC Extension Revived, cloud ARM emulator test

[hostilefork]

This brings the TCC extension building up to date. Changes to TCC itself had made it not work with ARMv5 any longer, and the Android NDK no longer supports GCC in current versions.

The process of cross-compiling TCC is isolated from the main build scripts into a helper script that is part of the TCC extension. This script retains the ability to build using older GCC-based NDKs. That involved several hacks, and those hacks are now isolated to if you are building using them.

(Comments in the files explain the laborious number of details that had to be attended to in order to get this to work!)

Because the only Android emulator that works with any performance is Mac-based, the cleanest way to test would be to build on a mac and then test on that same container. So this makes the build work on Macs as well.

The emulated Android device does not have a GNU toolchain installed, so it lacks the libc or headers necessary for functions like printf(). This takes advantage of the new feature of COMPILE of /NOSTDLIB to make sure that a compilation test can run in the emulator.

[hostilefork]

@giuliolunati This took a loooong time (several days, I've lost count) but... I really wanted to see this work!

I got it to call this native in the emulator:

call-librebol: make-native [
    "Show It's Possible to Call libRebol without GNU toolchain installed"
    n [integer!]
]{
    int n = rebUnboxInteger(rebArgR("n"));
    rebElide("print [{Hello, libRebol World:}", rebI(n), "]");
    return rebInteger(n + 20);
}
compilables: [call-librebol]

opts: [runtime_path %tcc/]  ; tcc-encap.zip is unzipped to tcc/

compile/settings/nostdlib compilables opts
print "COMPILE SUCCEEDED"

result: call-librebol 1000
print [{The result was:} result]

Here is the result (!)

The /NOSTDLIB feature is needed to do this, because I just put r3 on the Android emulator in the /data/tmp directory. I describe /NOSTDLIB here

Anyway, I'd really like to see your conference demo be set up as part of what is tested and kept working. Once it is part of the tests, then that keeps it on the radar and means I'd have to fix anything that went wrong. :-)

I notice there are some APIs for installing APKs. I've seen how to transfer files with ADB PUSH and ADB PULL... and it looks like there are automation APIs for doing keypresses and things like that. So it seems within the realm of possibility that we could test an ARM Ren-C server communicating with a Wasm Ren-C browser and have some confidence that it is working...

Anyway, I've learned a bit now and am able to help on all this.

[giuliolunati]

Hi Brian, great work! Tell me if I can help :-) ( ATM I'm working about image manipulation )

[hostilefork]

Tell me if I can help :-)

If you could make sure your .APK is up to date and working (on your phone / build environment), and get the build process for that APK into the script, I could see what I could do about the automated testing part...

A reason I'd like you to do it instead of me (besides giving me some time to look at something else for a minute :-P) is just for you to get a chance to know how GitHub CI works. You can even use Ren-C as a shell for a step!

Windows Build Line 260 - Ren-C as Shell

It has made me think that maybe we can package up dialects as tools that install into people's workflows. Actions can be made even for relatively trivial things to make them easier.

For instance, I use an action to install the NDK in the Android workflow. Installing the NDK isn't that hard, but this picks the right download link for your platform and the version number and decompresses it...and tells you where it decompressed it.

Anyway, yeah, if you can get the APK made and verify it works on your phone, then that would be helpful...