| Summary: | CMake support for android project | ||
|---|---|---|---|
| Product: | SDL | Reporter: | sfalexrog |
| Component: | build | Assignee: | Sylvain <sylvain.becker> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | admin, olli.kallioinen, registrirayme, sezeroz, sfalexrog |
| Version: | HG 2.1 | Keywords: | target-2.0.12 |
| Hardware: | All | ||
| OS: | Android (All) | ||
| Attachments: |
Enable CMake builds for Android
CMake documentation |
||
|
Description
sfalexrog
2017-10-24 12:54:42 UTC
Created attachment 3040 [details]
CMake documentation
I'd like to see better support for android cmake too. I saw your post on the forums and figured you'd probably have a fix submitted too. I also submitted a related fix: https://bugzilla.libsdl.org/show_bug.cgi?id=3823 that just disables the postfix on android, but I think your fix for the library naming is better overall. Maybe they should be combined. The problem that I see is that in debug mode your fix still builds a library called libSDL2d.so (with postfix 'd'). That will cause trouble when trying to load the library explicitly by name in the Java code because the name is different depending on debug/release mode. Everything works if you just list your own library and let android load the dependencies automatically, but there was an issue when loading dynamic libraries on Android that forced you to list all the dependencies in order. The issue was fixed on API level 18 (Jelly Bean 4.3.x), but as SDL still supports older API levels, all the libraries should be listed in getLibraries() for an app to work on older devices. Hopefully in a couple of years the SDL minimum version requirement is bumped up enough so we can get rid of that hack (well I personally already have). On my end, this also failed when directly build SDL2 by CMake... However, I have made a workaround for that in my project: https://github.com/WohlSoft/PGE-Project/blob/723c5774944dc1cc21c1199e07bb29d09ab0d048/_common/library_SDL2.cmake#L40-L87 My project is fully CMake-building, and it does use of "external projects" to build all dependent libraries to link them. Because SDL2 can't be built with CMake directly, I made an ugly workaround for that to build through NDK Make and manual copying of certain files into the correct folder. Sylvain, can you look at this? Yes, I looked at it. And Thanks for the patchs! I have commited in https://hg.libsdl.org/SDL/rev/4a410f099040 what I was been able to test. some more fix: - un-activated HIDAPI https://hg.libsdl.org/SDL/rev/4a410f099040#l3.9 and only link it when needed: https://hg.libsdl.org/SDL/rev/4a410f099040#l1.19 - fix for ndk-20 (at least) when the nativeRunMain try to dlopen to call the main() function https://hg.libsdl.org/SDL/rev/4a410f099040#l1.7 - I cannot build for armeabi-v7a because it requires cpufeatures. the compilation is solved here: https://hg.libsdl.org/SDL/rev/4a410f099040#l3.11 but it still needs so cmake magic to link.. - At some point, I had an issue with the compilation, because of the inclusion of immintrin.h I wonder whether, in the file include/SDL_config.h.cmake, #cmakedefine HAVE_IMMINTRIN_H 1 should be replaced by #cmakedefine HAVE_IMMINTRIN_H @HAVE_IMMINTRIN_H@ I've added some cmake code so that SDL_image/SDL_mixer/SDL_ttf also compile with Android and CMake. But this is partially working/compiling, some external dependencies are missing a CMakeLists.txt, and not well tested. https://hg.libsdl.org/SDL/rev/8e299f937b6c https://hg.libsdl.org/SDL_image/rev/4ac6bc242c62 https://hg.libsdl.org/SDL_mixer/rev/8b275092fdbb https://hg.libsdl.org/SDL_ttf/rev/0d923dcf4fba About SDL Mixer: I have my own fork of SDL Mixer I have placed here: https://github.com/WohlSoft/SDL-Mixer-X and I using CMake build by default (I have removed all other builds because of unnecessary as CMake is much more universal than these others): https://github.com/WohlSoft/SDL-Mixer-X/blob/master/CMakeLists.txt It builds on these platforms: Linux, Windows, macOS, Android, Haiku. Not tested on xBSD and iOS. You can take my build as a reference. For Android / SDL_Mixer, CMake would need to trigger the compilation of FLAC/OGG/MPG123/MODPLUG/TIMIDITY, but they have no CMakeLists.txt. In you CMakeFiles.txt, you either rely on "system" or "pre-compiled library". Not sure for other platform, I don't know much cmake ... Speaking about build triggering: while libraries like OGG and Vorbis having their own CMake build, some others lack it. Therefore, I have made them myself. I made a special repository https://github.com/WohlSoft/AudioCodecs where I have placed all these libraries with full CMake build. FLAC, Opus, OpusFile, MAD, and some other libraries hadn't CMake build for example, and they have it written by me. I have a wish to make a similar CMake build for MPG123 too. Thanks, I added the CMakeLists.txt files for external libs. https://hg.libsdl.org/SDL_mixer/rev/c251a3a6a2df Indeed, mpg123 is missing. I only tested the compilation for Android, and didn't run it. Maybe this could also be tested with linux and other, and or be cleaned up to restrict this to Android. I did minor modifications of thoses CMakeLists.txt file: - paths with version - vorbis is splitted here in vorbisidec - add more include path, because we have direction for android/config types One note about FLAC: I have made a minor patch to it as it won't build with various MinGW/MinGW-w64 toolchains and fails on an attempt to use `_wutime64` call. I disabling it's using when it's unavailable (when compile tests fail). https://github.com/WohlSoft/AudioCodecs/commit/d78345a9668dda9641ae055aef4a8863f3056d27 And whops: the `HAFE_WUTIME64` macro contains a typo... It should be `HAVE_WUTIME64`, my old mistake... Also, some another FLAC's bug: https://github.com/WohlSoft/AudioCodecs/commit/df13b10b4862fa729aa7c16d524217c58246ce00 (In reply to Vitaly Novichkov from comment #12) > Also, some another FLAC's bug: > https://github.com/WohlSoft/AudioCodecs/commit/ > df13b10b4862fa729aa7c16d524217c58246ce00 Please report that to flac mainstream. (In reply to Ozkan Sezer from comment #13) > (In reply to Vitaly Novichkov from comment #12) > > Also, some another FLAC's bug: > > https://github.com/WohlSoft/AudioCodecs/commit/ > > df13b10b4862fa729aa7c16d524217c58246ce00 > > Please report that to flac mainstream. Ok, anyway, first off I should upgrade my FLAC copy to be sure bugs are still be here, and then report them if they are still. More fix for android/cmake, run an app using SDL_ttf, SDL_image and SDL_mixer. https://hg.libsdl.org/SDL_mixer/rev/c52db177a8bd https://hg.libsdl.org/SDL_ttf/rev/3c1e3d014c1c https://hg.libsdl.org/SDL_image/rev/32208515f967 Mark this as fixed! *** Bug 4595 has been marked as a duplicate of this bug. *** *** Bug 4616 has been marked as a duplicate of this bug. *** Does the patch somehow fixes this: https://bugzilla.libsdl.org/show_bug.cgi?id=4601 https://discourse.libsdl.org/t/android-building-sdl-2-0-10-with-cmake-gradle/26544/2 I have a custom project layout and use SDL2 as a dynamic library. Is hidapi supported on Android actually? If not why not disable it by default instead of this: android-project/app/jni/CMakeLists.txt # Settings set(HIDAPI OFF CACHE BOOL "" FORCE) I un-activated hidapi with cmake on android because it didn't compile at first. And I don't really use cmake on android. Fell free to submit a patch to solve this. Is hidapi really necessary? I applied to changes from the commit https://github.com/spurious/SDL-mirror/commit/79da113ed7eed61b97deb32d02834ccaa60bb0c6 , yet the following code gets called. And since there isn't a hidapi.so the alert is displayed. private HIDDeviceManager(final Context context) { mContext = context; // Make sure we have the HIDAPI library loaded with the native functions try { SDL.loadLibrary("hidapi"); } catch (Throwable e) { Log.w(TAG, "Couldn't load hidapi: " + e.toString()); AlertDialog.Builder builder = new AlertDialog.Builder(context); builder.setCancelable(false); builder.setTitle("SDL HIDAPI Error"); builder.setMessage("Please report the following error to the SDL maintainers: " + e.getMessage()); builder.setNegativeButton("Quit", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { Are there any other commits necessary to be applied? Is there an option to completely bypass that code/alert if hidapi isn't necessary on Android? I found the commit: https://github.com/spurious/SDL-mirror/commit/cb0aa75cfee550225e14a054fcb5edaa1a35dc17 If you don't want HIDAPI, modify SDLActivity.java, comment out: // mHIDDeviceManager = HIDDeviceManager.acquire(this); Maybe that info must be added to the README file. And maybe also it can be done via a variable which is set to true by default:
SDLActivity
if (isHIDAPIEnabled)
{
mHIDDeviceManager = HIDDeviceManager.acquire(this);
}
and can be changed by the user in the derived class as in my case.
Can you create a new bug for the HIDAPI alert dialog? Now hidapi compiles and run with Android/CMake. https://hg.libsdl.org/SDL/rev/bfed06214c2a We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. (In reply to Sylvain from comment #15) > More fix for android/cmake, run an app using SDL_ttf, SDL_image and > SDL_mixer. > > https://hg.libsdl.org/SDL_mixer/rev/c52db177a8bd > https://hg.libsdl.org/SDL_ttf/rev/3c1e3d014c1c > https://hg.libsdl.org/SDL_image/rev/32208515f967 Applied multiple fixes/cleanups to android cmake projects in SDL_mixer: https://hg.libsdl.org/SDL_mixer/rev/300088719593 The cmake stuff in SDL_mixer tree is incomplete, and that it being for android-only is stupid: Maybe we should remove?? Remove all the cmake ? Or remove the "if (android)" so that it applies to all platforms ? -I am not using a lot cmake. I created the file to fix/improve the android build with cmake. Maybe in the future we will be forced to use it.. (so we don't remove it). Currently I only tested on android, but if somehow want to use/improve it for other plateforms, this can be generalized. The best would be to have nothing/or the smalled related to a platform. For the record (again): I did not get email from bugzilla for the update you made to this entry (noticed it accidentally while browsing the web page of this bugzilla.) There is something WRONG with bugzilla emails. (In reply to Sylvain from comment #34) > Remove all the cmake ? > Or remove the "if (android)" so that it applies to all platforms ? Unless the cmake support is properly expanded to cover all supported platforms, I'd say remove it: why keep something half-baked? (quarter-baked even..) > -I am not using a lot cmake. I created the file to fix/improve the android > build with cmake. Maybe in the future we will be forced to use it.. (so we > don't remove it). > > Currently I only tested on android, but if somehow want to use/improve it > for other plateforms, this can be generalized. The best would be to have > nothing/or the smalled related to a platform. I'd say it should be generalized. |