The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

What's the best way to build a hello world SDL2 project with CMake for Android (on Windows)?

This question is relevant for me too right now.
If I figure out from all the sources out there, I'll post my solution here

You might want to check this out first . https://wiki.libsdl.org/Android The guide is WIP since forever (guess everyone is too busy), so you might have to do some more research on your own end as wll.
And then this https://hg.libsdl.org/SDL/file/tip/docs/README-android.md

With that said I haven't got it working myself. I've also tried including SDL as a sub project (and use the toolchain file from https://github.com/taka-no-me/android-cmake) without success (it somehow failed to compile).

Last but not least, I think the Android toolchain works better in Linux or OSX than Windows. Not really sure if that's just my imagination though.

Migrate to Android studio and gradle it works much better.
On Sun, Feb 7, 2016, 22:22 mr_tawan wrote:

Android Studio is unusable when it comes to anything more complex than
just some JNI-exported functions in NDK, unless you invoke ndk-build
directly from your Gradle script and use good old Android.mk-based build
system.

Just clone SDL to your jni/ directory, `include` its Android.mk in your
main Android.mk and add it to APP_MODULES in your Application.mk. And
copy SDLActivity to your project.

On 07/02/2016 17:40, Owen Hogarth II wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well some of us already have project written with CMake (I do have one). Android Studio does not currently support CMake though. I wish they would include the support (which is already in-use in CLion) into AS.

Anyway is there any guides for creating SDL projects with AS ?

The reason I try to use SDL2 and CMake is that these are IDE agnostic cross platform solutions for native game development. I used IntelliJ IDEA (works almost like Android Studio) with gradle for a simple 2048 clone in java, and it really worked great! But since it was java it meant that for the desktop version, the user had to have java on their machine. You might say that that is an acceptable dependency, but in two earlier projects I already had incompatibilities, one because openjdk doesn't have javafx by default, and another for which I don't know the reason but the application I wrote didn't run on a Mac (I don't have a Mac and couldn't try it out before sending it to my friend).
And the reason I want cross platform IDE agnostic solution is because I'm sick of how games mainly work only on Windows, and how any sane developer environment only works on Linux and it's derivatives, while the 95% of the logic is platform independent.
Also I might be insane but I want to have a solution that minimizes vendor lock in. That is: whoever want to tamper with my project can do so with any IDE which can parse CMake project structure and any compiler that can compile standard C/C++ code.

But in the long run I might give up, and simply go with the simplest working solution, so how would one use SDL2 with Android studio if I want to develop not only for Android but for Desktop and iOS too?

I am in the same boat as you, but with gradle if you already build with cmake all you have to do is write a gradle script to configure and run your cmake command. You do not have to change your cmake scripts, even if you do still want to swim upstream and struggle against google's decisions eventually that will fail because as an android developer you should know that once google depreciates something they tend to kill it with fire.

I develop on linux I migrated away from mac I haven't used windows in a long time. I can understand that you want to make your project as platform agnostic as possible but that's going to bring you a lot of headaches. Make sure it works on your primary dev machine first and build out from there. I write my c code with vim and script most of the other stuff because like you I got tired of vendor problems. CLion looked promising then they threw a curve ball with their silly pricing schemes.


Speaking of openJDK did you see this news: http://www.eweek.com/developer/googles-move-to-openjdk-to-benefit-developers.html


Google got burned by oracle "free java api" and they are moving to openjdk.


You are targeting android so you have to integrate with android studio for a little ease of use, it's not much and once you have setup one project you can basically copy paste that project since most of your logic in being done in c anyways.


Best,
Owen


On Mon, Feb 8, 2016 at 12:36 AM, qzole wrote:

Seems like Microsoft and NVidia is trying hard including supports for Android in CMake and Visual Studio.

I've tried using this method https://blogs.msdn.microsoft.com/vcblog/2015/12/15/support-for-android-cmake-projects-in-visual-studio/ (notice: it use MS's special version of CMAKE, they said they are working with Kitware though). I've still got some errors (undefined reference, -lpthread not found, etc.), but it pretty close to get things compile.

You might be interested in this patch: https://bugzilla.libsdl.org/show_bug.cgi?id=3234 (currently not applied to hg - but is needed to compile current hg with vs compilers)


I've got it somehow working via cmake - check out https://github.com/mgerhardy/caveexpress - it might be broken atm because travisCI only builds android on linux (but of course still with cmake)


regards

martin

On Sun, Feb 7, 2016 at 6:40 PM, mr_tawan wrote:



--
http://www.caveproductions.org

oh.. and sorry for the spam - but you might also be interested in this: http://mgerhardy.blogspot.de/2015/11/install-android-packages-via-cmake.html - this allows you to install android packages via cmake easily.


On Mon, Feb 8, 2016 at 1:31 PM, M. Gerhardy wrote:



--
http://www.caveproductions.org

Ah yes, I too stumbled into this issue. I circumvented it by turning off the warning <.<
Your patch is a better solution if SDL was meant to be used with C89 compilers.

I also bumped into some other issues:
- One was that there were missing declarations in `SDL_render_gles.c` file, which I fixed with a `#define GL_GLEXT_PROTOTYPES` at the top of the file
- Another was that pthreads wasn't found when linking, looking in the ndk directory it seemed that indeed there is no pthreads library so I turned it off by adding ANDROID to the condition in SDL's main CMakeLists.txt

After this, my project compiles using your toolchain file (which is taka-no-me's modified toolchain file if I'm not mistaken). So now I have a shared lib which should be bundled into an apk.

Thanks for the info, and thanks in clarifying that at least one of the issues I bumped into is a global issue with SDL and not something I misconfigured
I wonder if my other to issues are global or I did something wrong, right now I just want a working solution and want to work from there.

I almost get it compiled with Taka-No-Me's android-cmake toolchain, after I've manually changed a few generated makefile. The missing reference is SDL_main(), which probably means the main() (I built it straight from the code without include it to my project yet). From what I found -lpthread is not really needed in ndk. I have to add the -lGLESv1_CM, -lGLESv2, -llog and -landroid manually, btw.

I've got it compiled in Visual Studio using the MS's version of CMake I mentioned below as well. Using very similar method to above (without the toolchain file). It only compiles to object file, so I think I have to create a java project in Android Studio and put it there manually. Not very convenience, but it works at least. I haven't have time to test it yet though.

IMO, if SDL is written in C90/C89 standard, the android specific part should be written in that standard as well. At least of the consistency, and the warning (and the flag that promote it to an error) would not have to be turned off. I haven't checked how the warning is added to the makefile though. Probably in the cmake script, or may be in the toolchain file?

One more thing, it looks like this kind of question pops up every now and then (I searched the forum and see a number of threads). We may need to come up with a better solution, and post it in the wiki. Don't you think ?

For the SDL_main problem:
Even if you define SDL_main (the usual way of this is to have a standard main function with SDL.h or SDL_main.h header included, which has a #define to rename your main to SDL_main), you'll get undefined reference for main because an SDL android project doesn't have a main, it isn't meant to be compiled to be an executable, but as a shared library which is loaded by SDL's java Activity class. I chekced M. Gerhardy's working example and he does the same with with a handful of CMake macros. I also think you need that java wrapper even with MS's solution.

I also agree that the correct fix is to apply Martin's patch, me turning off the warning was just a quick fix.

Yes, this information should be summed up, and it should be in the official place, but first there should be a solution that works easily. It isn't really inviting if a half-baked solution is provided which needs 13 manual steps to work
Sadly it seems I won't be able to have to much spare time in the near future.

On 2/13/16, qzole wrote:

I just submitted a patch to make the code base C89 clean.
https://bugzilla.libsdl.org/show_bug.cgi?id=3264


I still maintain my Android patch and I think it is a good way of
doing it, originally announced here:
https://forums.libsdl.org/viewtopic.php?t=10263&sid=2888ecbb7fc048bbb49de54e0c357dda
But the repo has been moved here:
https://bitbucket.org/ewing/sdl_androidcmake

I've been planning to revisit getting this mainlined again. But I
wanted to get my use case out the door first so it would be easier to
explain some of the motivations. But ultimately, it is about making a
prebuilt Android library that follows standard platform conventions
that you can just download and link to, like we have for many of the
other platforms.

I actually just put out a teaser video today showing a use case of
prebuilt binaries in an SDL based SDK I've been developing. Though
ironically there's no Android yet because it is a Swift language
focused video (and haven't done the Swift port to Android yet).
https://youtu.be/w8ftI9mpGdY

This one actually shows the Android part in more detail, though it
still is a little high level. The main point is that SDL is prebuilt
and your application just links to it. (And I've already written all
the build system stuff, so my SDK users don't have to think about it.)
https://www.youtube.com/watch?v=exPtM-02YRY&index=3&list=PLfQSQ4hu539MKtZZLdFSK63QAmiep1Ksj

This is made possible by having a process that we can reliably build
SDL for Android as a prebuilt library ahead of time. There is also
some stuff to make the SDLmain entry point pre-build-able.

Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is in revision control now, thanks!

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I've just tried building using CMake today, using the taka-no-me's android toolchain file. After adding `add_definitions("-DGL_GLEXT_PROTOTYPES")` into my project's cmake file, to enable the OES EXT functions used by SDL, the code is now compiles. It does fail at the linking stage. I see 3 problems here :-

1. -lpthread is unwanted in Android. pthread library is usable even if it's not linked against to the lib file.
2. OpenGL ES functions is not linked to. This indicates that `-lGLESv1_CM` and `'lGLESv2` is not supplied to the linker.
3. A few android specific functions are not included into the build, causing undefined reference errors.

These three could be fix manually in the generated build file (which I have already tried once). Getting this into the CMake might be a bit challenging .

On 2/20/16, mr_tawan wrote:

So, as an FYI, I think all these things had been addressed in my
aforementioned AndroidCMake branch.

This was the initial commit from (yikes, quite) a while back.
https://bitbucket.org/ewing/sdl_androidcmake/commits/66c2d15f3abcbd84207557baa600e85574aef064

I had to do some merge resolution last week which I wasn't thrilled
about, but it's resolved (for now).

-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Having not followed this conversation (sorry!)...should I pull this branch into the main repo? Is it generally useful at this point?

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I've just read the commit message in the link you refer, and realized how ignorance I was :-).

On 2/21/16, Ryan C. Gordon wrote:

I believe my changes are useful and would like to see them mainlined.
I have successfully been using them to make prebuilt SDL binaries that
I can use in projects, as well as other people using my prebuilt
binaries in their projects. This provides an alternative to embedding
the entire SDL source tree into your project and building world. Build
systems are hard, and Android is particularly bad. And I spent a lot
of time vetting the compiler switches used by the CMake toolchain to
try to match what Android wants to do natively.

But before this should be mainlined, there were some concerns brought
up by Gabriel Jacobo. I was supposed to talk to you or Sam directly,
but I got sidetracked. I wanted to have more real world cases
demonstrating how these things are used, and thus beneficial. It’s
been a long time so my memory is hazy, but I think the crux of the
concerns were my changes to decouple Android application specific
things from the libSDL core. This manifested itself first by shifting
stuff to libSDLmain. But even that has some very per-application stuff
that prevents pre-compiling a libSDLmain, so I think the second thing
was I had to suggest a convention for the user’s main application .so.
There are #ifdef concenssions to try to not break existing behavior
where you compile everything as one gi-normous blob (though they
probably need to be retested since I haven’t touched them in so long).

Anyway, I’m happy to discuss these things in more detail. I want to
make sure everybody is happy before this gets pushed in. You did
happen to catch me at a strange time. I’m trying to get SwiftAndroid
working as we speak. This potentially may stress my changes. I’m
hoping to see that everything still holds without changes.

Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org