zoff99
commented
4 years ago i can't get it to work any way shape or form
Open ppetraki opened 4 years ago
zoff99
commented
4 years ago i can't get it to work any way shape or form
zoff99
commented
4 years ago @ppetraki i used the sledge hammer and it made all the trouble go away. even pkg-config can be used then
sed -i -e 's#self.is_cross =.*$#self.is_cross = True#' /work/meson_/meson-"$meson_version"/mesonbuild/compilers/c.py
ppetraki
commented
4 years ago @zoff99 I looked at the python code quite a bit, the way the cross-compilation support is done is frustrating to follow. I gave up. It also has killed Meson as a general build system for me. If hacking a bunch of untypesafe "stuff" is what I have to do to get the build system working on a new platform, well I already have that problem with Cmake; everyone already understands how to solve that problem.
If build2 ever does a cmake compatibility module. It would obsolete much of what meson has to offer.
gavr123456789
commented
4 years ago Any news about that? I am a newbee in meson, and I am interested in the case of using Meson to build an Android application with GLib.
ppetraki
commented
4 years ago @gavr123456789 They're not interested. Do you know that up to c++17 is available on Android? The STL outclasses glib, and you don't need to do anything special to use it.
gavr123456789
commented
4 years ago @ppetraki Ty for information, but I hate C++ ^^, I need it for Vala (something like go with generics, normal OOP, and C# syntax).
ppetraki
commented
4 years ago @gavr123456789 The build system is the least of your problems and is honestly something you need to just suck up and get through. Vala on Android is going to require you to get into the native C bindings before you get to do any real work. You're going to need glib and gobject too.
https://stackoverflow.com/questions/3041039/vala-for-android
Unless Google themselves is going to support meson, it's probably not ever going to happen. All those platform defs with nested conditional properties are written in cmake code and if meson can't harness it, then the android developers will have to rewrite it just for meson and maintain both until the end of time. It just doesn't add enough value.
mensinda
commented
3 years ago
Please see meson android PoC for context: https://github.com/ppetraki/meson-android-helloworld
I attempted to use https://github.com/mesonbuild/meson/issues/5102 as a reference and discovered multiple issues which hamper meson from being used easily with the Android NDK.
Reliance on pkgconfig It doesn't exist and is apparently used to divine MachineChoice.HOST
Declaring the use of the Android provided cmake binary isn't helpful without the cross compilation configuration. I can't find a way to actually drive said config into cmake. This is important as without it, calls to dependency will use the system paths which is an error.
The remaining issues are downstream from not being able to leverage the cmake cross compile defines and the environment it defines. Instead I have to define everything by hand, pass it in, and use get_option() to make use of the ndk library paths I manually setup just so I can link against the right version of libandroid.
The amount of config management I had to create to drive meson for the cross build exceeds the usefulness of meson itself. I still don't know whether I can use subprojects correctly. Especially ones that use cmake.
What has to happen to avoid maintaining a fork of the android config defs is to harness the cmake cross compile context, extract the necessary variables, and forward them to the build. Is there any interest in such a feature?