> 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.
I can definitely see the benefits of using CMake. We’ll see how far we get with our approach – one nice thing is that it’s very easy to add additional libraries (e.g. we added CoreBase the other day), plus it’s basically agnostic to the app’s build process (e.g. it works with both CMake/Android Studio and qmake/Qt). > We ran into a rather 'fun to find' arm64 ivar offset bug with the 1.9 runtime > and the latest ndk/clang. Sounds nasty. I assume you are talking about this fix <https://github.com/llvm/llvm-project/commit/ccc42869a7e30fcff7fd39f864a3e63c09bd0759> in clang? I wonder if Google is open to cherry-picking commits like this – do you think it’s worth a try to ask them about it? > 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? I’ve been working on a patch to support resource loading via AAssetManager in libs-base. It works by passing the Java asset manager to GNUstep via an initialization function, and then having various methods in NSFileManager and NSData use AAssetManager if a given path path has a prefix of NSBundle.mainBundle.resourcePath. It’s not very pretty but it was the only way I could come up with to support resource loading on Android. I’d be interested to hear any feedback on that approach and whether this is something that could be merged in the official release. Once it’s ready I’d be happy to open a pull request. If anyone is interested I can also share a patch of the work in progress (still a bit rough though). We also recently discovered JIGS <https://github.com/gnustep/libs-java> (aka libs-java) which looks very useful. Any idea whether it should work on Android? We’d mainly want to use it to call Android Java APIs from Objective C, although it sounds like <https://github.com/gnustep/libs-java/blob/82cddd7d7bb186976eaf9888e1c1fd1a06e754b5/Source/JIGSProxy.h#L51-L56> that direction might not be 100% supported yet (in contrast to calling Objective C code from Java). Frederik > Am 13.05.2019 um 18:33 schrieb Jordan Schidlowsky > <[email protected]>: > > 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] >> <mailto:[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 >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnustep> >> >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
