WIP: Glib building with meson for Android

[devingryu]

Initial PR for testing build in Azure Pipelines.

Note. libpcre is now required lib in latest glib, so manual building of it should be added.

[devingryu]

OK, now I'm wondering where did libpcre(v8.39) came from. Are there any process which caches or builds pcre, or is it just a misconfiguration of pkg-config?

[derselbst]

Ah, you mean because it says Run-time dependency libpcre found: YES 8.39. Strange. You could check with pkg-config --list-all. I've looked through the entire logs, and there's no trace of libpcre, except for meson claiming it's there. Maybe it's accidentally using the host-libpcre?

[devingryu]

Maybe it's accidentally using the host-libpcre?

I thinks this is most likely to be the case. Maybe manually setting pkg_config_libdir with env variable (when running isolated bash process for meson) could solve the issue.

I'll test it by tomorrow and commit this again.

[derselbst]

Meson does indeed use the host's libpcre:

https://dev.azure.com/tommbrt/tommbrt/_build/results?buildId=7186&view=logs&j=0dd91bf4-5270-5f6c-2450-fbc036057a53&t=a3415db1-8583-5d5c-45da-2fb90163a18e&l=10016

That's because pkg_config_libdir is only supported by meson >=0.54, however the pipeline runs in an ubuntu 20.04 where only meson 0.53 is available.

Since we cannot use a newer ubuntu CI image, and I don't want to compile meson myself, I thought it would be a good idea to simply use a recent ubuntu docker container and build in it. Well... it wasn't that simple. I could probably make it work, but it will probably take me yet another 4 hours to get it working...

Ideally, it should be possible to run meson without env -i. It should just use the same environment autotools and CMake are using. I tried that in the most recent android-meson-glib now, but now there is some meson sanity check failing. Perhaps you could have a look at this again. You can just merge that branch into yours.

libpcre is building fine already.

[devingryu]

It should just use the same environment autotools and CMake are using. I tried that in the most recent android-meson-glib now, but now there is some meson sanity check failing.

Sanity check is about CC and CXX variables. when CC and CXX is set, then meson detects them as build machine's compiler(not cross compiler), so they tries to run arm binaries in x86. That's why sanity check is failing, and that's why I used env -i.
We can consider using latest meson by using pip install meson. I'll try that.

[devingryu]

VOILA!!

OK, now you can check if fluidsynth works well with glib 2.71. As far as I know, there is no breaking API changes in glib 2.0, but there might be some unexpected problems like #1063.

Now I'll do some post-processing before you wake up (since it's morning here now...) like cherry-picking your android-meson-glib, so keep in mind.

[eli-schwartz]

Sounds like the Android NDK environment doesn't provide its own pkg-config wrapper as is customary, e.g. {TARGET_TRIPLE}-pkg-config typically sets up the PKG_CONFIG_LIBDIR and friends for any given cross compiler environment.

If one of those existed, you'd simply pass that as the pkg-config binary for Meson to use.

[devingryu]

e.g. {TARGET_TRIPLE}-pkg-config typically sets up the PKG_CONFIG_LIBDIR and friends for any given cross compiler environment.

Is that applicable for meson 0.53? If that's not the case, then it can't be used for this situation.

The problem is solved BTW, by setting PKG_CONFIG_LIBDIR inside env -i command.

[eli-schwartz]

It's worked since Meson 0.25, which had a bugfix to stop hardcoding the string 'pkg-config' in the implementation for the dependency() function and instead look for a pkgconfig entry in the cross file.

You may of course set $PKG_CONFIG_LIBDIR too, which is effectively what such a wrapper would do except that Meson does not know you've defined such a variable, so you'd need to ensure it is always set whenever invoking Meson, for example in the event that a meson.build file is edited and ninja triggers a buildsystem reconfigure.

(Either the wrapper edition of pkg-config, or the 0.54.0 pkg_config_libdir property, would be part of a persistent state.)

[derselbst]

Thanks @devingryu I've applied your change to my branch. Note that I had to remove the sys_root property, because otherwise pkgconfig reports wrong paths: https://dev.azure.com/tommbrt/tommbrt/_build/results?buildId=7214&view=logs&j=dc39b471-769f-561c-c6ee-ccd61ea5b976&t=937363f6-a93a-55a1-8383-bc1be5439593&l=9730 (and it surprises me that it still compiles fine...)

Also, when you don't provide libpcre, glib keeps downloading an older version of it. I prefer to compile it explicitly.

I think we can close this PR. I'll apply it on master shortly. I'm too cautious to ship this with 2.2.6 though, because the Android CI pipelines are not yet running the unit tests. This is on the TODO list (#912).

You already helped me a lot, thanks @devingryu !

[devingryu]

Also, when you don't provide libpcre, glib keeps downloading an older version of it. I prefer to compile it explicitly.

Actually, I was working on it. But if you've already done it, then I shall close this PR.

You already helped me a lot, thanks @devingryu !

Glad to hear that!

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information