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 <mr_tawan at hotmail.com> wrote:
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.mdWith 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.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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:
Migrate to Android studio and gradle it works much better.
On Sun, Feb 7, 2016, 22:22 mr_tawan <mr_tawan at hotmail.com <mailto:mr_tawan at hotmail.com>> wrote:
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. _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
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 ?
Owen Hogarth II wrote:
Migrate to Android studio and gradle it works much better.
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:
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,
OwenOn Mon, Feb 8, 2016 at 12:36 AM, qzole <kurucz.zoltan87 at gmail.com> wrote:
Owen Hogarth II wrote:
Migrate to Android studio and gradle it works much better.
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?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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
martinOn Sun, Feb 7, 2016 at 6:40 PM, mr_tawan <mr_tawan at hotmail.com> 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.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
oh… and sorry for the spam - but you might also be interested in this:
- this allows you to install android packages via cmake easily.On Mon, Feb 8, 2016 at 1:31 PM, M. Gerhardy <@Martin_Gerhardy> wrote:
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
martinOn Sun, Feb 7, 2016 at 6:40 PM, mr_tawan <mr_tawan at hotmail.com> 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.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.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.cfile, which I fixed with a#define GL_GLEXT_PROTOTYPESat 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 ?
mr_tawan wrote:
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.
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:
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).
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.)
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,
EricOn 2/13/16, qzole <kurucz.zoltan87 at gmail.com> wrote:
mr_tawan wrote:
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.
I just submitted a patch to make the code base C89 clean.
https://bugzilla.libsdl.org/show_bug.cgi?id=3264
This is in revision control now, thanks!
–ryan.
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 :-
- -lpthread is unwanted in Android. pthread library is usable even if it’s not linked against to the lib file.
- OpenGL ES functions is not linked to. This indicates that
-lGLESv1_CMand'lGLESv2is not supplied to the linker. - 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 :).
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.
I had to do some merge resolution last week which I wasn’t thrilled
about, but it’s resolved (for now).
-EricOn 2/20/16, mr_tawan <mr_tawan at hotmail.com> wrote:
I’ve just tried building using CMake today, using the taka-no-me’s android
toolchain file. After addingadd_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 :-
- -lpthread is unwanted in Android. pthread library is usable even if it’s
not linked against to the lib file.- OpenGL ES functions is not linked to. This indicates that
-lGLESv1_CM
and'lGLESv2is not supplied to the linker.- 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
:).
So, as an FYI, I think all these things had been addressed in my
aforementioned AndroidCMake branch.
Having not followed this conversation (sorry!)…should I pull this branch into the main repo? Is it generally useful at this point?
–ryan.
Eric Wing wrote:> On 2/20/16, mr_tawan <@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’ve just read the commit message in the link you refer, and realized how ignorance I was :-).