Thanks. Yes I've been following what you and Greg have been doing with the tools-android project, great work! We kinda abandoned gnustep-config and gnustep-make and just wrote CMakeLists.txt for everything. As David eluded to earlier in this thread, it's kinda the lesser of all evils at this point regarding C/C++ build systems... It was appreciated when we built everything with ASan, and when debugging in Android Studio to track down bugs, etc.
We ran into a rather 'fun to find' arm64 ivar offset bug with the 1.9 runtime and the latest ndk/clang. Happened VERY rarely, and was quite difficult to find and identify as it usually failed silently with unexpected values in ivars. But I've got a few months to get everything running on arm64 before our deadline hits, so I'm hoping to get everything running on the 2.X runtime. The latest beta NDK clang is r346389, which doesn't include what looks like a few important commits David has made to fix a _Bool ivar encoding size which I'm particularly worried about. At any rate, the latest NDK may not include the clang we need so I will probably just build clang manually. Regarding android support in libs-base, I'm curious what your strategy is for things like say NSBundle? Planning on supporting any API in that class, or just going to punt? > On May 7, 2019, at 2:06 PM, Frederik Seiffert <[email protected]> wrote: > > Congratulations on the release, really great to see GNUstep used in the wild > like this! > > As we’ve also been working on an GNUstep Android toolchain > <https://github.com/gnustep/tools-android> (announcement forthcoming by Greg > Casamento), I’d love to see if we can somehow combine our efforts towards > making GNUstep work great on Android. > > Our solution to managing the build process has been a collection of concise > scripts <https://github.com/gnustep/tools-android/tree/master/phases>, one > for each library, to pre-build the toolchain into a common shared location > (for all ABIs). An Android project can then integrate the toolchain by > calling gnustep-config in that location to get the necessary compiler/linker > flags (e.g. from CMake as shown > <https://github.com/gnustep/android-examples/blob/master/hello-objectivec/app/src/main/cpp/CMakeLists.txt#L12-L42> > in our Android Studio example project). > > Other than that our setup seems very similar (e.g. using libdispatch and > ARC), but it’d be great to hear where it differs from yours. We also have an > integration with Qt internally (including integrating libdispatch with the Qt > run loop) which I hope to share as another example. > > While we’re still a long way from shipping something with this setup we’re > pretty happy with our early prototypes using it. > > As a side node, as of today the toolchain also works on arm64 and x86/x86_64 > (great for using the emulator) using the gnustep-1.9 runtime (we tried using > the 2.0 runtime but ran into an issue > <https://github.com/gnustep/libobjc2/issues/90> with the clang version that > is part of the NDK, but hopefully we can make the switch with a future NDK > release). > > Frederik > > >> Am 04.05.2019 um 05:49 schrieb Jordan Schidlowsky >> <[email protected] <mailto:[email protected]>>: >> >> Hey all, just wanted to share with everyone on the list we FINALLY launched >> our Android game built on GNUstep, Golf Blitz. It of course has an iOS >> counterpart but the Android build is built on top of GNUstep. If you have >> an android device you can find it easily in the Google Play store by >> searching for "Golf Blitz", it's free. It's a quite strange multiplayer >> golf game... >> >> Some highlights: >> >> Runtime: gnustep-runtime-1.9 >> Arch: armv7a softfp >> Graphics: GLESv2, cocos2d >> Uses blocks, arc, and libdispatch heavily. Libdispatch isn't built into any >> runloop and we kinda bootstrap the apps main thread onto a java render >> thread... We also just drain the main dispatch queue manually and the start >> of our game loop. >> Libs-base version: 9bcef37ae0bdf2ce5a1baacac2a3288cb39e2f03 >> Cloud game servers: Google cloud >> >> Next up on my todo list is the get the game running on the 2.1 runtime >> (thanks David for all your work!), as Google has a requirement that all new >> game updates have to be built as arm64 binaries by August. I definitely >> will be able to provide a decent amount of testing for that runtime and arch. >> >> Cheers, >> -Jordan >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
