Support building application for Android

[sp1ritCS]

It should be possible to build gtk applications written in rust for the new android backend, given that the rust bindings do not use introspection at build time (sources are pregenerated).

As far as I see, there are two issues that are currently preventing this:

1. For android, we want a "single-pass" ninja invocation to build the whole source+dependency tree, which as far as I understand isn't possible with rust, as it wants to use pkg-config to resolve the dependencies.
2. The glue code wants to call main(int argc, char **argv, char **envp), as I doubt that rustc will expose such an entry symbol by itself, there is likely need for more glue.

My potential idea was to build the rust application as static library, as to avoid rustc doing any symbol resolving. Instead meson should take the produced static library and link it with its dependencies built from the subprojects (this has the added benefit of meson also automatically linking the glue in correctly).

[sdroege]

GStreamer is building plugins on Android (and iOS) since quite a while (using gstreamer-rs etc), but has all kinds of hacks to make this work. We did not figure out a clean way to also build Android (or iOS) apps unfortunately, but there are ideas/plans. You might want to look at GStreamer first to get an idea as most problems will also apply to GTK.

Related is also gtk-rs/gtk-rs-core#1196 gtk-rs/gir#1600 and linked issues, etc.

[sp1ritCS]

@sdroege I did get gstreamer itself to build on android already (for getting the Clapper media player working). Probably not the way it was intended to work (gstreamer building itself and plugins into a single shared object, instead I had to manually copy all built plugins into libdir and set GST_PLUGIN_SYSTEM_PATH_1_0 to libdir, which seemingly worked), but adding gstreamer caused the number of ninja targets to jump up from about 2500 to 10000 and this probably excludes any rust plugins as I doubt it was able to find the right compiler.

gtk-rs/gir#1600

Moved the link instruction into the build.rs, but as far as I understand there is currently no mechanism to prevent link instructions (/ pkg-config lookups) altogether, is there?

[bilelmoussaoui]

Moved the link instruction into the build.rs, but as far as I understand there is currently no mechanism to prevent link instructions (/ pkg-config lookups) altogether, is there?

That is done through system-deps, in https://github.com/gtk-rs/gtk4-rs/blob/main/gtk4/sys/build.rs#L13 for example. If using that for Android is not possible, we can add a #[cfg(not(target_os = "android"))] there.

[sp1ritCS]

@bilelmoussaoui I'd be interested in hearing your opinion in moving the final linking stage into meson.

If using that for Android is not possible, we can add a #[cfg(not(target_os = "android"))] there.

I'd be a lot better if you could detect if the target it is building is a static library (or rlib?) and skip it based on that.

[bilelmoussaoui]

@bilelmoussaoui I'd be interested in hearing your opinion in moving the final linking stage into meson.

That is up to the applications, the code in build.rs doesn't do any linking as far as I know, it just ensures the right version is available.

[sp1ritCS]

the code in build.rs doesn't do any linking as far as I know, it just ensures the right version is available

It doesn't? Building gtk-rs applications do fail tho if the pkg-config packages aren't installed.

[bilelmoussaoui]

As I mentioned above, that is because of the system-deps checks.

[sp1ritCS]

Could these be skipped when building a static library?

[sdroege]

I'm not sure what you're proposing here. Why would you want to skip the pkg-config checks at all for any target?

[sp1ritCS]

I'm not sure what you're proposing here. Why would you want to skip the pkg-config checks at all for any target?

To avoid needing to install the dependencies, as the whole project+dependency tree should be built by a single ninja invocation.

[sdroege]

But you would need to have those dependencies in place anyway. If you build them as part of the whole project, then e.g. meson gives you -uninstalled.pc files that can be used for that purpose.

Skipping the pkg-config files seems like a hack to work around other problems.

[sp1ritCS]

@sdroege The -uninstalled.pc won't work as meson considers pkg-config to not exist (which is the correct behaviour as there is no pkg-config in the NDK)

Skipping the pkg-config files seems like a hack to work around other problems.

There really is just no need for pkg-config, that's all.

I've got a working build by setting PKG_CONFIG to /bin/echo before running cargo, but that is obv. not a solution.

[sdroege]

The -uninstalled.pc won't work as meson considers pkg-config to not exist (which is the correct behaviour as there is no pkg-config in the NDK)

We're using pkg-config to link the correct libraries for GStreamer (on Android and elsewhere), so simply disabling this will break things for us.

There really is just no need for pkg-config, that's all.

The only supported way to link against GLib and everything else is via pkg-config though :)

[sp1ritCS]

We're using pkg-config to link the correct libraries for GStreamer (on Android and elsewhere)

GStreamer itself resolves its libraries via meson, which may (or may not) use pkg-config. Where are you explicitly using pkg-config to resolve stuff?

so simply disabling this will break things for us.

I still don't see why you'd need pkg-config when building a static library, given that this won't do any foreign "linking".

The only supported way to link against GLib and everything else is via pkg-config though :)

Its perfectly legitimate to pull in glib as a meson subproject, in which case pkg-config is not used.