Support for languages other than C?

[haecker-felix]

Have an exposed main(int, char**, char**) entrypoint (reduced parameters are allowed) that ends up calling g_application_run before it returns

Is it also somehow possible to package GNOME/GTK apps which are not written in C, let say for example Rust?

[sp1ritCS]

The main issue with non-c/c++ languages is that pixiewood expects applications to be built "single-pass" (i.e. a singe ninja invocation can build the application from nothing but the android ndk toolchain). According to @ebassi is is currently impossible to do so with support for gobject-introspection, which the other languages need (esp. the python/javascript/lua ones).
I could imagine it being possible for Vala & Rust with a bit of "hacking", as long as you don't depend on Android backend-specific APIs. For Vala might be possible to just have valac produce C source code and just to throw that into gnome.executable, while for Rust you might get away with building your application as a static library (no idea how its runtime handles initialization, you probably want to replace the main function with extern "C" main(argc, argv, envp)), and have meson link_whole the .a into the executable.

I'd love to see support for additional languages (I've already tried looking if I could build some gnome core/circle apps for demo purposes, but all of the "simple" ones aren't written in C :(), so if you manage to get something working let me know (or tell me if you are facing any issues I could potentially resolve).

[Biswa96]

Is there any Gnome app written in C ported to Android (other than gtk demo) ? Also, could you name any "other than C" project?

[sp1ritCS]

Is there any Gnome app written in C ported to Android (other than gtk demo) ?

There's the libadwaita demo that is reasonable to build (it either needs patching to remove the appstream dep or appstream needs patching to make its meson build work in a cross environment)
and also I get my Fidei to build, but it requires changes to the meson files.

Also, could you name any "other than C" project?

I was thinking it'd nice if I could maybe build gnome-calculator given that it doesn't have to interface with the OS, but its written in Vala and I'd need introspection for a single pass build for that.

[Biswa96]

I was thinking it'd nice if I could maybe build gnome-calculator given that it doesn't have to interface with the OS

I added gnome-calculator in a different Android repository termux/termux-packages@9d89db4. So, it's not impossible, I guess 🙂

I'll explore this new idea.

[sp1ritCS]

So, it's not impossible, I guess 🙂

Termux doesn't need to single-pass build the whole software stack. You just depend on g-ir-scanner, which was already built previously.

[theCapypara]

I have an app written in Python I'd like to eventually port. Python just recently also got tier 3 Android support.
I'll probably at least play around with it for a while, even if it's probably impossible in the current state.

Unfortunately I don't really know any Perl, so not sure how well I can really hack around here...

[Biswa96]

Unfortunately I don't really know any Perl, so not sure how well I can really hack around here...

Neither do I. Instead, I build the project in the container and modified it in Android Studio. I am wondering if https://gitlab.gnome.org/GNOME/jhbuild could be used for building the native binaries.

[sp1ritCS]

even if it's probably impossible in the current state.

Yes, right now its definitively impossible. We'll at least need
a) meson build scripts for python (very likely as a patch, I doubt they want it upstream given how well their autotools build works)
b) mesons python module will have to be able to find the python it is building itself
c) mesons gnome module generate_dir should be able to use the build machine g-ir-scanner with --use-binary-wrapper and --use-ldd-wrapper
d) a bit of additional glue code that uses libpython to import your application and runs it

Unfortunately I don't really know any Perl, so not sure how well I can really hack around here...

While I did try to keep the pixiewood code understandable, you don't have to hack around in it. Pixiewood is mostly acting as a wrapper for running meson/ninja parallely and responsible for generating the android application skeleton (AndroidManifest.xml, build.gradle, app icons, etc.), there is still functionality missing (e.g. mapping appstream manifest permissions to android manifest permissions) that'll have to be implemented, but for integrating python I don't think you'll have to modify pixiewood at all.

---

Instead, I build the project in the container and modified it in Android Studio.

For development, your kinda supposed to use android-studio anyways. Thats why pixiewood build --skip-gradle exists, as that'll just cause pixiewood to ninja build & install the native libraries and assets to the correct location, and recompile the gschemas but not build the apk, as pressing run/debug in Studio does that then.

[sp1ritCS]

FYI: For rust my idea with treating cargo as a "dumb compiler" and letting meson do the final linking seems to work.

A proof of concept is located here: https://github.com/sp1ritCS/gtkrs4droid/

[sp1ritCS]

I've managed to produce introspection data and build pygobject. The required changes are far from ready getting upstreamed yet and involves a lot of manual shuffling of files to their correct location; but its possible.

If anyone is feeling experimental, here is a copy of the studio project tree. As this is python, you can modify its behavior without recompiling by modifying the files in app/src/main/assets/share/{python3.14,pyapp}. Keep in mind that updates will only extract the assets into the filesystems if app/src/main/assets/afpr doesn't match the previous. You'll have to fill it with 128 new random bytes when doing changes, or modify the behaviour of SystemFilesystem.java.