This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Enable CMake builds for Android (android_cmake.patch, text/plain, 2017-10-24 12:54:42 +0000, 5271 bytes)
• CMake documentation (README-android.patch, text/plain, 2017-10-24 18:54:10 +0000, 2538 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2017-10-24 12:54:42 +0000, wrote:

Created attachment 3039
Enable CMake builds for Android

(bug 3166 possibly related)

Google seems to be pushing for a CMake-based build system for projects with native code. This should make porting existing projects simplier, if said projects already use CMake. Google also suggests using CMake for new projects, as well as choosing to add CMakeLists.txt over Android.mk

Since SDL2 already has CMake support, it's easy to include it in an Android build, with minimal modifications. Then one could follow the build instructions for Android, replacing ndk-build with cmake.

I'm relatively new to CMake, but it seems to be quite versatile and allows elaborate build processes without resorting to other tools (which might not be available on some platforms). Cross-platform (Linux/Windows) software seems to adopt CMake as their meta-build system, and with IDEs getting CMake integration (Visual Studio 2017, CLion) this will probably become more popular. Having a single build system should simplify cross-platform development significantly.

I'm attaching patches to SDL's CMakeLists.txt, as well as to android-project's build.gradle. The cmake parts are commented-out by default (in case the developer doesn't need cmake; currently gradle only supports one build system), but can be easily enabled.

On 2017-10-24 18:54:10 +0000, wrote:

Created attachment 3040
CMake documentation

On 2018-01-16 13:00:53 +0000, Olli Kallioinen wrote:

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 2019-08-02 22:38:24 +0000, Vitaly Novichkov wrote:

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.

On 2019-08-06 06:48:20 +0000, Sam Lantinga wrote:

Sylvain, can you look at this?

On 2019-08-11 13:35:34 +0000, Sylvain wrote:

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@

On 2019-08-13 14:06:02 +0000, Sylvain wrote:

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

On 2019-08-13 14:30:48 +0000, Vitaly Novichkov wrote:

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.

On 2019-08-13 14:46:31 +0000, Sylvain wrote:

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 ...

On 2019-08-13 14:55:06 +0000, Vitaly Novichkov wrote:

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.

On 2019-08-14 07:53:31 +0000, Sylvain wrote:

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

On 2019-08-14 09:22:03 +0000, Vitaly Novichkov wrote:

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).

WohlSoft/AudioCodecs@d78345a

And whops: the HAFE_WUTIME64 macro contains a typo... It should be HAVE_WUTIME64, my old mistake...

On 2019-08-14 09:26:11 +0000, Vitaly Novichkov wrote:

Also, some another FLAC's bug: WohlSoft/AudioCodecs@df13b10

On 2019-08-14 09:36:14 +0000, Ozkan Sezer wrote:

(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.

On 2019-08-14 10:01:30 +0000, Vitaly Novichkov wrote:

(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.

On 2019-08-15 16:17:15 +0000, Sylvain wrote:

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

On 2019-08-15 18:43:52 +0000, Sylvain wrote:

Mark this as fixed!

On 2019-08-21 10:22:55 +0000, Sylvain wrote:

*** Bug 4595 has been marked as a duplicate of this bug. ***

On 2019-08-22 07:21:03 +0000, Sylvain wrote:

*** Bug 4616 has been marked as a duplicate of this bug. ***

On 2019-08-24 10:09:46 +0000, ZZ wrote:

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.

On 2019-08-24 10:17:48 +0000, ZZ wrote:

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)

On 2019-08-24 15:14:42 +0000, Sylvain wrote:

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.

On 2019-08-25 08:49:12 +0000, ZZ wrote:

Is hidapi really necessary?

On 2019-08-25 18:41:05 +0000, ZZ wrote:

I applied to changes from the commit spurious/SDL-mirror@79da113 , 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) {

On 2019-08-25 18:51:55 +0000, ZZ wrote:

Are there any other commits necessary to be applied?

On 2019-08-25 18:59:16 +0000, ZZ wrote:

Is there an option to completely bypass that code/alert if hidapi isn't necessary on Android?

I found the commit:
spurious/SDL-mirror@cb0aa75

On 2019-08-25 18:59:57 +0000, Sylvain wrote:

If you don't want HIDAPI, modify SDLActivity.java,

comment out:
// mHIDDeviceManager = HIDDeviceManager.acquire(this);

On 2019-08-25 19:50:18 +0000, ZZ wrote:

Maybe that info must be added to the README file.

On 2019-08-25 20:13:07 +0000, ZZ wrote:

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.

On 2019-08-26 17:12:37 +0000, Sam Lantinga wrote:

Can you create a new bug for the HIDAPI alert dialog?

On 2019-08-27 09:40:20 +0000, Sylvain wrote:

Now hidapi compiles and run with Android/CMake.
https://hg.libsdl.org/SDL/rev/bfed06214c2a

On 2019-09-20 20:47:38 +0000, Ryan C. Gordon wrote:

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.

On 2019-09-20 20:48:42 +0000, Ryan C. Gordon wrote:

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.

On 2019-12-01 10:23:33 +0000, Ozkan Sezer wrote:

(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??

On 2019-12-01 21:08:45 +0000, Sylvain wrote:

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.

On 2019-12-01 23:02:52 +0000, Ozkan Sezer wrote:

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.