Skip to content

Support for languages other than C? #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
haecker-felix opened this issue Feb 1, 2025 · 10 comments
Open

Support for languages other than C? #2

haecker-felix opened this issue Feb 1, 2025 · 10 comments

Comments

@haecker-felix
Copy link

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
Copy link
Owner

sp1ritCS commented Feb 1, 2025

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
Copy link

Biswa96 commented Feb 4, 2025

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
Copy link
Owner

sp1ritCS commented Feb 4, 2025

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
Copy link

Biswa96 commented Feb 4, 2025

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
Copy link
Owner

sp1ritCS commented Feb 4, 2025

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
Copy link

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
Copy link

Biswa96 commented Feb 20, 2025

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants