Android patch: Build via CMake, fixes, SDLmain, Android SDL binaries, and Android project examples

SDL Development
1

I am submitting a patch for inclusion that improves the build process,
usage process, and quality of the binaries for Android. (It does
contain some code fixes too.)

My repo may be found here:
https://bitbucket.org/ewing/sdl_android_cleanup

This patch makes it possible to build SDL using CMake.

  • This attempts to leverage a lot of the existing infrastructure which
    hopefully ensures correctness and enables optimizations (e.g.
    architecture specific optimizations)
  • Additionally, the build process is geared so it is possible and easy
    to distribute SDL binaries for Android (for armeabi, armeabi-v7a, x86)
    which should vastly improve the user experience.
  • I also have a working libSDLmain.so.

I also have posted separate example projects of how to use prebuilt
binaries using the official NDK external module system
(NDK_MODULE_PATH). I have one example done in Ant, and the other in
Gradle. Unfortunately, we are in this sucky transition period where
Google is ditching Ant/Eclipse for Gradle/Android Studio, and the NDK
support is still a disaster.

The external projects can be found at:
https://bitbucket.org/ewing/helloandroidsdl-ant
https://bitbucket.org/ewing/helloandroidsdl-gradle
Also, the download page for each project contains the prebuilt Android
SDL binaries I built. So you can download them and test. (Eventually,
we should be able to do official binary releases.)
I would eventually like to deprecate/remove the existing project
template and either put these in its place, or just put documentation
on how users can create their own projects (because there isn’t that
much infrastructure needed once you have prebuilt external SDL
libraries in the external NDK module system).

There is a lot of information to cover. I’m sure it will be
information overload. Android development sucks in general so expect
this to be painful. My goal in doing this is to make everybody’s lives
less painful on Android because what I have now is a significant
improvement believe it or not. This is the 4th real world project I’ve
done through this (Chipmunk, ALmixer, JavaScriptCore, the latter being
absolute hell) so I’m pretty confident about all this. (This is the
first time I’ve tried Gradle though.)

There is a README-AndroidCMake.txt in build-scripts which discusses
how to build SDL using Android-CMake. (Note: I require the use of the
Android NDK ‘standalone toolchain’).

My Android.mk contains additional information on how to use the
NDK_MODULE_PATH system because the Google documentation is terrible.

My external example projects both contain README.txt files on how to use them.

Areas of discussion I would like to have:

  • About the SDLmain and hardcoded libMySDLMainActivity.so name. I
    think we could make this more flexible by making it possible to pass
    the library name through the nativeInit() function as an extra
    parameter. (I think another fair discussion is if SDLmain was really
    worth it.)

  • Also, my binaries are built with -Os. I did a little, but not much
    performance testing. I didn’t see any difference in speed using -Os,
    so I think this should be the default (which is what I committed in my
    helper scripts).

  • How to improve the project templates (like is there a way we can
    make an actual project template in Android Studio?)

Please feel free to ask questions.

My commit log message is pasted below for convenience:

The goals of this Android-CMake patch are to:

  • Build SDL correctly
  • Build SDL for all the proper Android architectures (currently
    armeabi, armeabi-v7a, x86)
  • Build SDL for Android with the best optimizations and features enabled
  • Build an External NDK Module (distributable binaries) suitable for
    everybody to use so everybody doesn’t have to build SDL from scratch
  • Leverage a single/correct/authoritive build system to minimize
    accidental differences in the build process or from one system getting
    neglected/stale
  • Simplify things

See the build-scripts/README-AndroidCMake.txt for more information.

Here are some interesting code related areas concerning this patch:

  • I removed the -O3 from the CMake script. This is the wrong thing to
    do because it clobbers anything specified by the CMake build type.

  • SDLmain now works but has caveats:

– libSDLmain.a doesn’t work because it is dropping the symbols during
linking. I think the problem is that since we need to build a .so on
Android instead of an app, linking libSDLmain.a causes unused symbols
to be disregard

— I noticed the libSDLmain.a is always built for every platform.
This should be reconsidered, but I didn’t change it.

– libSDLmain.so is provided as an alternative. But this required some
fancy dancing with SDL_LoadObject/SDL_LoadFunction to defer symbol
resolution to runtime because there is no SDL_main yet when we build
libSDLmain.so.

— Additionally, we need to hard code the name of the user .so. I
have picked libMySDLMainActivity.so to help disambiguate any confusion
between the user’s stuff and the libSDLmain.so we provide.

  • JNIEXPORT / JNICALL needed to be used for all our JNI bridge
    functions because CMake is using symbols=hidden by default. This is
    correct thing to do anyway, and shrinks binary size and improves
    calling performance.

  • SDL_Android_Init gave me a lot of trouble because this also needs to
    be exported now that we have a libSDLmain that must call private stuff
    in the libSDL2 library. This symbol must be exported, but for reasons
    I don’t understand, the standard DECLSPEC macros didn’t work for me.
    So I just used gcc visibility attributes directly.

  • I removed the use of SDL_internal.h in the SDL_android_main.c. It’s
    bad since that lives outside SDL. It also appears it is unneeded.

  • There seems to be a bug in the Find Pthreads module for CMake where
    it was using check_c_source_runs instead of check_c_source_compiles.
    (The former will never work in a cross-compiled environment.)

  • I bundled a copy of my version of the android.toolchain.cmake. It is
    a fork from the one OpenCV posted. I made a lot of fixes to it. I
    haven’t yet figured out if they are still maintaining it and if we
    can/should merge.

Thanks,
Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

2

That’s a lot of work! Thanks!

I need some time to process this, a few knee jerk reactions:

  • You can probably build SDL_android_main.c into libSDL2.so (like the
    current project does), that way you only depend on one external symbol
    (SDL_main). Given this is Android oriented, and that you’ll always need to
    have SDL entry point, you can make this simplification.

  • I’m a bit hesitant to add a separate build system dependent on an
    external tool. The current build system is cumbersome, but it works out of
    the box with just the Android NDK and SDK installed. Of course the argument
    can be made that this just sits along the current system, but the
    maintenance cost is going to increase :slight_smile:

  • If there are code bug fixes, it would be nice if you can submit them
    separately on Bugzilla.

Gabriel.

2014-04-25 3:30 GMT-03:00 Eric Wing :> I am submitting a patch for inclusion that improves the build process,

usage process, and quality of the binaries for Android. (It does
contain some code fixes too.)

My repo may be found here:
https://bitbucket.org/ewing/sdl_android_cleanup

This patch makes it possible to build SDL using CMake.

  • This attempts to leverage a lot of the existing infrastructure which
    hopefully ensures correctness and enables optimizations (e.g.
    architecture specific optimizations)
  • Additionally, the build process is geared so it is possible and easy
    to distribute SDL binaries for Android (for armeabi, armeabi-v7a, x86)
    which should vastly improve the user experience.
  • I also have a working libSDLmain.so.

I also have posted separate example projects of how to use prebuilt
binaries using the official NDK external module system
(NDK_MODULE_PATH). I have one example done in Ant, and the other in
Gradle. Unfortunately, we are in this sucky transition period where
Google is ditching Ant/Eclipse for Gradle/Android Studio, and the NDK
support is still a disaster.

The external projects can be found at:
https://bitbucket.org/ewing/helloandroidsdl-ant
https://bitbucket.org/ewing/helloandroidsdl-gradle
Also, the download page for each project contains the prebuilt Android
SDL binaries I built. So you can download them and test. (Eventually,
we should be able to do official binary releases.)
I would eventually like to deprecate/remove the existing project
template and either put these in its place, or just put documentation
on how users can create their own projects (because there isn’t that
much infrastructure needed once you have prebuilt external SDL
libraries in the external NDK module system).

There is a lot of information to cover. I’m sure it will be
information overload. Android development sucks in general so expect
this to be painful. My goal in doing this is to make everybody’s lives
less painful on Android because what I have now is a significant
improvement believe it or not. This is the 4th real world project I’ve
done through this (Chipmunk, ALmixer, JavaScriptCore, the latter being
absolute hell) so I’m pretty confident about all this. (This is the
first time I’ve tried Gradle though.)

There is a README-AndroidCMake.txt in build-scripts which discusses
how to build SDL using Android-CMake. (Note: I require the use of the
Android NDK ‘standalone toolchain’).

My Android.mk contains additional information on how to use the
NDK_MODULE_PATH system because the Google documentation is terrible.

My external example projects both contain README.txt files on how to use
them.

Areas of discussion I would like to have:

  • About the SDLmain and hardcoded libMySDLMainActivity.so name. I
    think we could make this more flexible by making it possible to pass
    the library name through the nativeInit() function as an extra
    parameter. (I think another fair discussion is if SDLmain was really
    worth it.)

  • Also, my binaries are built with -Os. I did a little, but not much
    performance testing. I didn’t see any difference in speed using -Os,
    so I think this should be the default (which is what I committed in my
    helper scripts).

  • How to improve the project templates (like is there a way we can
    make an actual project template in Android Studio?)

Please feel free to ask questions.

My commit log message is pasted below for convenience:

The goals of this Android-CMake patch are to:

  • Build SDL correctly
  • Build SDL for all the proper Android architectures (currently
    armeabi, armeabi-v7a, x86)
  • Build SDL for Android with the best optimizations and features enabled
  • Build an External NDK Module (distributable binaries) suitable for
    everybody to use so everybody doesn’t have to build SDL from scratch
  • Leverage a single/correct/authoritive build system to minimize
    accidental differences in the build process or from one system getting
    neglected/stale
  • Simplify things

See the build-scripts/README-AndroidCMake.txt for more information.

Here are some interesting code related areas concerning this patch:

  • I removed the -O3 from the CMake script. This is the wrong thing to
    do because it clobbers anything specified by the CMake build type.

  • SDLmain now works but has caveats:

– libSDLmain.a doesn’t work because it is dropping the symbols during
linking. I think the problem is that since we need to build a .so on
Android instead of an app, linking libSDLmain.a causes unused symbols
to be disregard

— I noticed the libSDLmain.a is always built for every platform.
This should be reconsidered, but I didn’t change it.

– libSDLmain.so is provided as an alternative. But this required some
fancy dancing with SDL_LoadObject/SDL_LoadFunction to defer symbol
resolution to runtime because there is no SDL_main yet when we build
libSDLmain.so.

— Additionally, we need to hard code the name of the user .so. I
have picked libMySDLMainActivity.so to help disambiguate any confusion
between the user’s stuff and the libSDLmain.so we provide.

  • JNIEXPORT / JNICALL needed to be used for all our JNI bridge
    functions because CMake is using symbols=hidden by default. This is
    correct thing to do anyway, and shrinks binary size and improves
    calling performance.

  • SDL_Android_Init gave me a lot of trouble because this also needs to
    be exported now that we have a libSDLmain that must call private stuff
    in the libSDL2 library. This symbol must be exported, but for reasons
    I don’t understand, the standard DECLSPEC macros didn’t work for me.
    So I just used gcc visibility attributes directly.

  • I removed the use of SDL_internal.h in the SDL_android_main.c. It’s
    bad since that lives outside SDL. It also appears it is unneeded.

  • There seems to be a bug in the Find Pthreads module for CMake where
    it was using check_c_source_runs instead of check_c_source_compiles.
    (The former will never work in a cross-compiled environment.)

  • I bundled a copy of my version of the android.toolchain.cmake. It is
    a fork from the one OpenCV posted. I made a lot of fixes to it. I
    haven’t yet figured out if they are still maintaining it and if we
    can/should merge.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

3

That’s a lot of work! Thanks!

I need some time to process this, a few knee jerk reactions:

I understand.

  • You can probably build SDL_android_main.c into libSDL2.so (like the
    current project does), that way you only depend on one external symbol
    (SDL_main). Given this is Android oriented, and that you’ll always need to
    have SDL entry point, you can make this simplification.

This is an interesting idea. I’m a little nervous about that idea
though because I’m going to start pushing the envelope on how I’m
going to use SDL. I want to use it in situations where SDL is just an
add-in library instead of driving the entire application. I worry
about accidental duplicate symbols caused by unneeded things.

In fact, I think this would break the more conservative approach of
where the user finds our implementation of SDL_android_main.c
lacking/unusable and decides to make custom modifications. They can
easily opt-out of libSDLmain and go back to including
SDL_android_main.c directly in their project as an override without
touching libSDL, but if we build that symbol directly into libSDL, I
think they will have problems.

  • I’m a bit hesitant to add a separate build system dependent on an
    external tool. The current build system is cumbersome, but it works out of
    the box with just the Android NDK and SDK installed. Of course the argument
    can be made that this just sits along the current system, but the
    maintenance cost is going to increase :slight_smile:

I understand and sympathize. However, I strongly believe this is the
correct thing and the better solution. I’ve been fighting Android for
about 4 years now. Google’s NDK build chain is total crap.

From the NDK vantage point, the built-in chain is very crippled. For
example, you can’t even pick an optimization setting of -Os without
directly hacking the NDK toolchain itself. (This is absurd on a system
that limits .apk sizes to 50MB and needs to ship multiple
architectures.) A more recent absurdity is they finally added hardware
floating point registers. However, the feature is completely
incompatible with any code that touches the JNI layer. Since they
constantly make you cross into Java for things (e.g. AssetManager),
you can’t apply this flag globally. But the NDK build chain doesn’t
allow you to set flags on a per-file basis. Hence, pretty much nobody
uses this flag and leaves performance on the floor. (In contrast, the
standalone toolchain and CMake don’t suffer from these limitations.)

From the CMake vantage point, we get to leverage a system that is
shared/common with the other platforms. So I claim the maintenance is
easier/better than what exists today. Part of my patch includes fixes
that were caught by building through the shared/common CMake chain
which the existing system missed/didn’t know about, such as proper
symbol export control. This is a common problem with reinventing the
build process.

The people who wrote the SDL CMake chain have some pretty nice checks
and diagnostics. This is an excerpt of one of the arm targets:On 4/25/14, Gabriel Jacobo wrote:

=============================================================
– SDL2 was configured with the following options:

– Platform: Linux-1
– 64-bit: FALSE
– Compiler: /Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-gcc

– Subsystems:
– Atomic: ON
– Audio: ON
– Video: ON
– Render: ON
– Events: ON
– Joystick: ON
– Haptic: ON
– Power: ON
– Threads: ON
– Timers: ON
– File: ON
– Loadso: ON
– CPUinfo: ON
– Filesystem: ON

– Options:
– 3DNOW (Wanted: ON): OFF
– ALSA (Wanted: OFF): OFF
– ALSA_SHARED (Wanted: OFF): OFF
– ALTIVEC (Wanted: ON): OFF
– ARTS (Wanted: OFF): OFF
– ARTS_SHARED (Wanted: OFF): OFF
– ASSEMBLY (Wanted: ON): ON
– ASSERTIONS (Wanted: auto): auto
– CLOCK_GETTIME (Wanted: OFF): OFF
– DIRECTFB_SHARED (Wanted: OFF): OFF
– DIRECTX (Wanted: OFF): OFF
– DISKAUDIO (Wanted: ON): ON
– DUMMYAUDIO (Wanted: ON): ON
– ESD (Wanted: OFF): OFF
– ESD_SHARED (Wanted: OFF): OFF
– FUSIONSOUND (Wanted: OFF): OFF
– FUSIONSOUND_SHARED (Wanted: OFF): OFF
– GCC_ATOMICS (Wanted: ON): ON
– INPUT_TSLIB (Wanted: OFF): OFF
– LIBC (Wanted: ON): ON
– MMX (Wanted: ON): OFF
– NAS (Wanted: OFF): OFF
– NAS_SHARED (Wanted: OFF): OFF
– OSS (Wanted: OFF): OFF
– PTHREADS (Wanted: ON): ON
– PTHREADS_SEM (Wanted: ON): ON
– PULSEAUDIO (Wanted: OFF): OFF
– PULSEAUDIO_SHARED (Wanted: OFF): OFF
– RENDER_D3D (Wanted: OFF): OFF
– RPATH (Wanted: OFF): OFF
– SDL_DLOPEN (Wanted: ON): ON
– SNDIO (Wanted: OFF): OFF
– SSE (Wanted: ON): OFF
– SSE2 (Wanted: OFF): OFF
– SSEMATH (Wanted: OFF): OFF
– VIDEO_ANDROID (Wanted: ON): ON
– VIDEO_COCOA (Wanted: OFF): OFF
– VIDEO_DIRECTFB (Wanted: OFF): OFF
– VIDEO_DUMMY (Wanted: ON): ON
– VIDEO_MIR (Wanted: OFF): OFF
– VIDEO_OPENGL (Wanted: ON): OFF
– VIDEO_OPENGLES (Wanted: ON): ON
– VIDEO_WAYLAND (Wanted: OFF): OFF
– VIDEO_X11 (Wanted: OFF): OFF
– VIDEO_X11_XCURSOR (Wanted: OFF): OFF
– VIDEO_X11_XINERAMA (Wanted: OFF): OFF
– VIDEO_X11_XINPUT (Wanted: OFF): OFF
– VIDEO_X11_XRANDR (Wanted: OFF): OFF
– VIDEO_X11_XSCRNSAVER (Wanted: OFF): OFF
– VIDEO_X11_XSHAPE (Wanted: OFF): OFF
– VIDEO_X11_XVM (Wanted: OFF): OFF
– X11_SHARED (Wanted: OFF): OFF

– CFLAGS:
–sysroot=/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot
-march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections
-ffunction-sections -fpic -fstack-protector -no-canonical-prefixes
-Wa,–noexecstack
– EXTRA_CFLAGS: -D_REENTRANT -fvisibility=hidden
– EXTRA_LDFLAGS:
– EXTRA_LIBS:
m;/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot/usr/lib/libdl.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot/usr/lib/liblog.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot/usr/lib/libandroid.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot/usr/lib/libGLESv1_CM.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/arm-linux-androideabi-4.6/sysroot/usr/lib/libGLESv2.so

– Build Shared Library: ON
– Build Static Library: ON

=============================================================
And this is the x86:

– Options:
– 3DNOW (Wanted: ON): ON
– ALSA (Wanted: OFF): OFF
– ALSA_SHARED (Wanted: OFF): OFF
– ALTIVEC (Wanted: ON): OFF
– ARTS (Wanted: OFF): OFF
– ARTS_SHARED (Wanted: OFF): OFF
– ASSEMBLY (Wanted: ON): ON
– ASSERTIONS (Wanted: auto): auto
– CLOCK_GETTIME (Wanted: OFF): OFF
– DIRECTFB_SHARED (Wanted: OFF): OFF
– DIRECTX (Wanted: OFF): OFF
– DISKAUDIO (Wanted: ON): ON
– DUMMYAUDIO (Wanted: ON): ON
– ESD (Wanted: OFF): OFF
– ESD_SHARED (Wanted: OFF): OFF
– FUSIONSOUND (Wanted: OFF): OFF
– FUSIONSOUND_SHARED (Wanted: OFF): OFF
– GCC_ATOMICS (Wanted: ON): ON
– INPUT_TSLIB (Wanted: OFF): OFF
– LIBC (Wanted: ON): ON
– MMX (Wanted: ON): ON
– NAS (Wanted: OFF): OFF
– NAS_SHARED (Wanted: OFF): OFF
– OSS (Wanted: OFF): OFF
– PTHREADS (Wanted: ON): ON
– PTHREADS_SEM (Wanted: ON): ON
– PULSEAUDIO (Wanted: OFF): OFF
– PULSEAUDIO_SHARED (Wanted: OFF): OFF
– RENDER_D3D (Wanted: OFF): OFF
– RPATH (Wanted: OFF): OFF
– SDL_DLOPEN (Wanted: ON): ON
– SNDIO (Wanted: OFF): OFF
– SSE (Wanted: ON): ON
– SSE2 (Wanted: OFF): OFF
– SSEMATH (Wanted: OFF): OFF
– VIDEO_ANDROID (Wanted: ON): ON
– VIDEO_COCOA (Wanted: OFF): OFF
– VIDEO_DIRECTFB (Wanted: OFF): OFF
– VIDEO_DUMMY (Wanted: ON): ON
– VIDEO_MIR (Wanted: OFF): OFF
– VIDEO_OPENGL (Wanted: ON): OFF
– VIDEO_OPENGLES (Wanted: ON): ON
– VIDEO_WAYLAND (Wanted: OFF): OFF
– VIDEO_X11 (Wanted: OFF): OFF
– VIDEO_X11_XCURSOR (Wanted: OFF): OFF
– VIDEO_X11_XINERAMA (Wanted: OFF): OFF
– VIDEO_X11_XINPUT (Wanted: OFF): OFF
– VIDEO_X11_XRANDR (Wanted: OFF): OFF
– VIDEO_X11_XSCRNSAVER (Wanted: OFF): OFF
– VIDEO_X11_XSHAPE (Wanted: OFF): OFF
– VIDEO_X11_XVM (Wanted: OFF): OFF
– X11_SHARED (Wanted: OFF): OFF

– CFLAGS:
–sysroot=/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot
-fdata-sections -ffunction-sections -no-canonical-prefixes
-funwind-tables -fstack-protector -Wa,–noexecstack
– EXTRA_CFLAGS: -D_REENTRANT -msse -m3dnow -mmmx -fvisibility=hidden
– EXTRA_LDFLAGS:
– EXTRA_LIBS:
m;/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot/usr/lib/libdl.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot/usr/lib/liblog.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot/usr/lib/libandroid.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot/usr/lib/libGLESv1_CM.so;/Library/Frameworks/Android/android-ndk-r9b/standalone/x86-4.6/sysroot/usr/lib/libGLESv2.so

– Build Shared Library: ON
– Build Static Library: ON

One thing I found interesting was it automatically figured out to
enable MMX and SSE on x86 but not arm.

Another thing I found interesting is that CLOCK_GETTIME is off. I
think it is available on Android. Maybe we should enable it. But I
would have never thought to check/test this option by myself. This is
another advantage of leveraging the expertise that already exists.

And finally, this is totally geared to producing binaries we can ship
so everybody doesn’t have to build SDL in their own local projects.
That’s just another point of failure. End users of SDL shouldn’t need
to worry about building it or CMake or the standalone toolchain since
they can just use binaries.

As I said, this is the 4th major project I’ve done using this
technique. It was developed because the native alternative was causing
us a lot of scalability and correctness problems.

  • If there are code bug fixes, it would be nice if you can submit them
    separately on Bugzilla.

The code fixes are mostly dealing with symbol exports (JNICALL, etc.).
I saw in the mailing list archive, this has been complained about
before.

If you are recommending trying to split/redo the patch, in this case,
I don’t recommend doing that. The patch I have is actually tested and
reimplementing it for the sake of splitting it up is just a way to
introduce new mistakes. If anything needs further adjusting, it is
better to just commit them as further revisions in my branch and then
do the final merge after.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

4

2014-04-25 16:34 GMT-03:00 Eric Wing :

  • You can probably build SDL_android_main.c into libSDL2.so (like the
    current project does), that way you only depend on one external symbol
    (SDL_main). Given this is Android oriented, and that you’ll always need
    to
    have SDL entry point, you can make this simplification.

This is an interesting idea. I’m a little nervous about that idea
though because I’m going to start pushing the envelope on how I’m
going to use SDL. I want to use it in situations where SDL is just an
add-in library instead of driving the entire application. I worry
about accidental duplicate symbols caused by unneeded things.

I’m all for experimenting but I don’t think that use case should be
supported on the official SDL distribution (but that’s my personal opinion
only!).
My reasoning behind this is that the Android landscape is complex enough
and we are too few people that we don’t need to task ourselves with yet
another source of random bugs where a third party is in charge of setting
the environment up while SDL sits on the sidelines.

In fact, I think this would break the more conservative approach of
where the user finds our implementation of SDL_android_main.c
lacking/unusable and decides to make custom modifications. They can
easily opt-out of libSDLmain and go back to including
SDL_android_main.c directly in their project as an override without
touching libSDL, but if we build that symbol directly into libSDL, I
think they will have problems.

This goes back to my previous paragraph, I don’t think using a non standard
SDL_android_main.c should be officially supported. Special needs projects
can always be handled by rebuilding the library and customizing anything
you want.

  • I’m a bit hesitant to add a separate build system dependent on an
    external tool. The current build system is cumbersome, but it works out
    of
    the box with just the Android NDK and SDK installed. Of course the
    argument
    can be made that this just sits along the current system, but the
    maintenance cost is going to increase :slight_smile:

I understand and sympathize. However, I strongly believe this is the
correct thing and the better solution. I’ve been fighting Android for
about 4 years now. Google’s NDK build chain is total crap.

From the NDK vantage point, the built-in chain is very crippled. For
example, you can’t even pick an optimization setting of -Os without
directly hacking the NDK toolchain itself. (This is absurd on a system
that limits .apk sizes to 50MB and needs to ship multiple
architectures.) A more recent absurdity is they finally added hardware
floating point registers. However, the feature is completely
incompatible with any code that touches the JNI layer. Since they
constantly make you cross into Java for things (e.g. AssetManager),
you can’t apply this flag globally. But the NDK build chain doesn’t
allow you to set flags on a per-file basis. Hence, pretty much nobody
uses this flag and leaves performance on the floor. (In contrast, the
standalone toolchain and CMake don’t suffer from these limitations.)

Yes, I agree on all counts with this. The old build system should die, but
it is what you get when you open that can of worms called Android
development system :slight_smile:

If you are recommending trying to split/redo the patch, in this case,
I don’t recommend doing that. The patch I have is actually tested and
reimplementing it for the sake of splitting it up is just a way to
introduce new mistakes. If anything needs further adjusting, it is
better to just commit them as further revisions in my branch and then
do the final merge after.

Smaller patches are easier to digest, test and accept, and you certainly
have my word that you won’t need to suffer through a lengthy discussion on
build systems if they fix bugs :)–
Gabriel.

5

I’m all for experimenting but I don’t think that use case should be
supported on the official SDL distribution (but that’s my personal opinion
only!).

I will have a more concrete proposal within the next 2 months. I’ve
already talked to Sam about this and will discuss this with you as I
get more things prototyped. I’ve mentioned this in another thread, but
yes, some of things things I want to leave ‘possible, but not
official’. A few of the lower level things I want to make official
(but optional). The latter gets into the event loop problem which is
also a problem on Mac and iOS and I expect to be an increasing problem
as operating systems become more focused on things like battery life.
(Again, a better discussion for another day.)

In fact, I think this would break the more conservative approach of
where the user finds our implementation of SDL_android_main.c
lacking/unusable and decides to make custom modifications. They can
easily opt-out of libSDLmain and go back to including
SDL_android_main.c directly in their project as an override without
touching libSDL, but if we build that symbol directly into libSDL, I
think they will have problems.

This goes back to my previous paragraph, I don’t think using a non standard
SDL_android_main.c should be officially supported. Special needs projects
can always be handled by rebuilding the library and customizing anything
you want.

I agree, we don’t have to support non-standard SDLmains. (I was
involved in this route for the last decade with SDLmain on Mac.)
However, taking a ‘do no harm’ approach, embedding this directly in
libSDL does not really improve the situation in any substantial way
for anybody (our prebuilt templates and boiler plate code have to set
this up anyway) and causes the potential harm of interfering with what
people may need to do. Keeping it off to the side in the
pre-established SDLmain convention ‘does no harm’ and spares people
from needing to muck with the core libSDL for simple customizations.

Yes, I agree on all counts with this. The old build system should die, but
it is what you get when you open that can of worms called Android
development system :slight_smile:

If you are recommending trying to split/redo the patch, in this case,
I don’t recommend doing that. The patch I have is actually tested and
reimplementing it for the sake of splitting it up is just a way to
introduce new mistakes. If anything needs further adjusting, it is
better to just commit them as further revisions in my branch and then
do the final merge after.

Smaller patches are easier to digest, test and accept, and you certainly
have my word that you won’t need to suffer through a lengthy discussion on
build systems if they fix bugs :slight_smile:

Would you be available for Skype or something so we can do a live code
review? (I’m trying to figure out how to save myself a bunch of time
while communicating the most amount of information.) Using a tool like
SourceTree, we can (easily) visually look at the changes in each file
and go over each one to your satisfaction.

Thanks,
Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

6

This is a bit late, but none-the-less:> Date: Fri, 25 Apr 2014 17:13:40 -0300

From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] Android patch: Build via CMake, fixes, SDLmain,
Android SDL binaries, and Android project examples
Message-ID:

Content-Type: text/plain; charset=“utf-8”

2014-04-25 16:34 GMT-03:00 Eric Wing :

  • You can probably build SDL_android_main.c into libSDL2.so (like the
    current project does), that way you only depend on one external symbol
    (SDL_main). Given this is Android oriented, and that you’ll always need
    to
    have SDL entry point, you can make this simplification.

This is an interesting idea. I’m a little nervous about that idea
though because I’m going to start pushing the envelope on how I’m
going to use SDL. I want to use it in situations where SDL is just an
add-in library instead of driving the entire application. I worry
about accidental duplicate symbols caused by unneeded things.

I’m all for experimenting but I don’t think that use case should be
supported on the official SDL distribution (but that’s my personal opinion
only!).
My reasoning behind this is that the Android landscape is complex enough
and we are too few people that we don’t need to task ourselves with yet
another source of random bugs where a third party is in charge of setting
the environment up while SDL sits on the sidelines.

SDL doesn’t need to do anything except to not prevent it. In the
absence of INTERCAL’s COMEFROM, SDL’s implementation of main can be
abstracted to:
platform_main()
{
void data (void)0;
SDL_preinit( &data );
SDL_callmain( &data );
SDL_postinit( &data );
}
This could be used to e.g. imitate Android’s “restart an old process
instead of making a new one” behavior by wrapping SDL_callmain() in a
loop.

In fact, I think this would break the more conservative approach of
where the user finds our implementation of SDL_android_main.c
lacking/unusable and decides to make custom modifications. They can
easily opt-out of libSDLmain and go back to including
SDL_android_main.c directly in their project as an override without
touching libSDL, but if we build that symbol directly into libSDL, I
think they will have problems.

This goes back to my previous paragraph, I don’t think using a non standard
SDL_android_main.c should be officially supported. Special needs projects
can always be handled by rebuilding the library and customizing anything
you want.

In which case you might as well just make a branch and not
back-commit, since you’ll have no way to avoid breaking changes. This
is a poor reason to avoid an opaque data structure and three new
functions (or something equivalent).