gnome: Added 'executable' method for GTK Android

[sp1ritCS]

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.

[sp1ritCS]

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]

I'm also somewhat unhappy about the type declarations for mypy, it seems somewhat hacky. But I have really no idea how it works

[tristan957]

It would be good to get some thoughts from other GNOME/GTK devs.

[sp1ritCS]

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

[tristan957]

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.

[jpakkane]

As this is an Android specific thing, putting it in the gnome module does not really make sense. I'd expect other devs would want to use it as well.

[sp1ritCS]

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

[sp1ritCS]

Any suggestions on how I could implement this in an acceptable way to get this merged?

[nirbheek]

Hm, it's not actually clear to me what the purpose of this method is. It's "just" adding a dependency and linking to a library? What is that introspection flags thing for?

[sp1ritCS]

It's "just" adding a dependency and linking to a library?

Basically yes. The glue dependency is a link_whole of a static library containing the glue code.

Regarding your note on gitlab of "just as well by conditionally using executable() or shared_library() in the meson build", I see a) some issues of code duplication as AFAIK there is no way of conditionally picking a function to which the same args should apply to and b) I don't want users to have to understand the "internals" needed to get their application running on android. Basically the same as on other platforms: It'd be quite weird to have to call a different function to define an executable target on each of linux/osx/win32.

What is that introspection flags thing for?

That gtk-android-builder can ideally scan the targets introspection and find the name of the library it needs to generate the java code that loads the library: application.xsl

[nirbheek]

I see a) some issues of code duplication as AFAIK there is no way of conditionally picking a function to which the same args should apply to and b) I don't want users to have to understand the "internals" needed to get their application running on android. Basically the same as on other platforms: It'd be quite weird to have to call a different function to define an executable target on each of linux/osx/win32.

I fully support the idea that Meson should be able to output an APK, or at least output artifacts that can be used to generate an APK without having to do ugly things in the build files. I just don't think this API is appropriate for that.

This PR is mixing three different things in one API:

1. JNI specifics, how an executable app is loaded and its entrypoint called; exactly the same technique as a shared module (plugin).
2. GTK-specific glue library code that needs to be linked in
   • Why isn't this pulled in automatically via the gtk4.pc file on Android? Is it meant to only be used by executables, and shouldn't be linked into libraries or plugins like a gstreamer plugin or something?
3. gtk-android-builder integration via introspection
   • We could automatically add this to the introspection for all targets that link to the gtk-android-glue library

(1) really shouldn't reside in the GNOME module. There is prior art in the win_subsystem kwarg, which does something similar for Windows. We could add something like android_activity: 'library' | 'exe'.

[sp1ritCS]

I fully support the idea that Meson should be able to output an APK

Outputting an directly APK is impossible I'm afraid, as the native code (the meson project) needs to be built for multiple architectures, the results of which will be packed into the apk. Thats why gtk-android-builder exists after all. Its main task (besides generating the application skeleton) is to run meson setup & ninja in parallel.

Is it meant to only be used by executables, and shouldn't be linked into libraries or plugins like a gstreamer plugin or something?

correct

There is prior art in the win_subsystem kwarg, which does something similar for Windows.

See my initial attempt for this: #13767, it adds an android_usecase kwarg to switch between application and executable. What this is missing there is a mechanism of registering an android glue dep (probably via crossfile) it should link into executables with android_usecase: 'application'. But I personally find this PR much better than the generic (still seems really specific for my problem) solution in that PR.

[nirbheek]

Is it meant to only be used by executables, and shouldn't be linked into libraries or plugins like a gstreamer plugin or something?

correct

The use-case of "I want to link to the same thing in two different ways" also exists for python, which is why it ships python3.pc and python3-embed.pc, and apps should use the right one. GTK could do the same, by shipping gtk4.pc and gtk4-android.pc (or something). Even glib ships gio-unix-2.0 and gio-win32-2.0.

That way even people who want to use CMake to build their app will be able to do the right thing.

[sp1ritCS]

GTK could do the same, by shipping gtk4.pc and gtk4-android.pc (or something).

Then you have the extra tweaks necessary that your application builds for android again.

I don't want users to have to change their executable(..., dependencies: [...], ...), statement to build_target(host_machine.system() == 'android' ? 'shared_library' : 'executable', '...', dependencies: [...] + host_machine.system() == 'android' ? dependency('gtk4-android') : [], ...).

That way even people who want to use CMake to build their app will be able to do the right thing.

Given that they need to use gtk-android-builder to build an application skeleton, people are forced to use meson for this purpose.