gnome: Added 'executable' method for GTK Android #13800
Conversation
|
Oh and I wanted to know if there is maybe a better way of removing executable specific kwargs for the shared library than just setting them to None? I'd also want to be able determine using the target introspection data which target originated from gnome.executable but am unsure how to achieve this. |
sp1ritCS
force-pushed
the
gnome_app
branch
2 times, most recently
from
dfa3b48
to
0e75aca
Compare
|
I'm also somewhat unhappy about the type declarations for mypy, it seems somewhat hacky. But I have really no idea how it works |
Previsouly, android_usecase was expected now import('gnome').executable
should be used to indicate applications supporting android.
sp1ritCS
force-pushed
the
gnome_app
branch
2 times, most recently
from
3372f22
to
9ca4b1e
Compare
|
It would be good to get some thoughts from other GNOME/GTK devs. |
|
btw, who's responsible for vala compiler support in meson? I'd expect that building an gnome.executable[1] that uses vala sources to behave in the end the same as an executable that uses c. This is not the case however with meson producing rather nonsensical ninja files. [1]: I doubt this has anything to do with this changeset that introduces gnome.executable, but rather the build pipeline that gtk-android-builder ends up producing, but its obv. related |
|
I'm not sure who owns it. I would talk to the Vala people on matrix or discord. I can't remember where they hang out. We could definitely use more Vala contributors. |
|
As this is an Android specific thing, putting it in the |
|
I don't really believe it makes a lot of sense for anything outside of building Android applications based on a GTK codebase. I know you can build QT Applications for Android aswell, but I don't know if they target "single shared codebase" like what I target to do. So unless you have a good plan on how to genericize this in a way that benefits building QT applications using meson for Android, I don't really see another place for it |
gnome.executable takes in the same arguments as mesons own executable, but it automatically builds a shared library on android and links it with gtk4-android-glue.
Using <target>.add_introspection_flag high level concepts can mark a specific target in the introspection data.
A new concept for #13767, this time more specifically tailored to GNOME/GTK.
I think having the "gtk4-android-glue" depname hardcoded is fine for now but it makes sense in the future to extend by scanning whether the user is depending on gtk4, 5, ... once there are different possibilities.