With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.
This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jylänki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)
Joseph Carter
There's a whole set of configure tests for BSD's libusbhid, and they only matter on BSD. However, if you have the library on Linux, it gets pulled in as library bloat. And it's bloat of the highest order since not a single function call to the library is ever made unless you're on a *BSD.
If ac_x_libraries is empty it means that the library's found in the default path,
so we skip adding it to the XLIB variable as it screws up the search path.
Ryan C. Gordon
If you have the X11 SDK installed on Mac OS X, you'll build with X11 support, but the Makefile doesn't build anything but the Cocoa testnative code for Mac OS X, which is fine, but then testnative fails to link because testnative.h enables the X11 support based on the SDL config header.
Building the testnativex11.c code on Mac OS X doesn't work because you need to explicitly link with "-L/usr/X11/lib -lX11" if this code is enabled, but you can't link with that by default because the X11 SDK might be missing.
So this needs a little configure magic to do the right thing (or forcibly disabling X11 support on Mac OS X in testnative.h).
Scott Percival 2011-07-03 06:41:51 PDT
This submission is aimed at making life easier for OpenGL ES capable devices
running a X11 stack (e.g. Maemo, Meego, TrimSlice, other ARM SoC boards not
running Android). SDL's Pandora support already has the neccesary GLES-to-X11
glue code, however it's all ghetto'd off in Makefile.pandora and not very
flexible.
The patch:
- adds an awesome --enable-video-opengles option to configure
- re-modifies the opengles and opengles2 SDL_renderers to use function pointers
- no idea why this was removed?
- for SDL_Renderers, links in libGLESv1_CM, libGLES_CM (for PowerVR fans) or
libGLESv2 at runtime
- links in libEGL.so at runtime - the old code made an assumption that
eglFunctions could be pulled from the active GLES library, PowerVR for one
doesn't let you do that with their libGLESv2
- allows you to pick which of GLES v1 or v2 to load via
SDL_GL_CONTEXT_MAJOR_VERSION
So far I've tested this on a Nokia N900 (OMAP 3430/SGX 530 running Maemo 5) and
a Toshiba AC100 (Tegra 2 running Ubuntu 10.10). I haven't tested it on... well,
everything that isn't those two, such as a Pandora, iOS or Android device. The
Pandora specific code should be kept intact (fingers crossed), and nothing
painfully drastic has been added to the SDL_renderers. The library loading
sequence in SDL_x11opengles has been updated to accomodate both NVIDIA's
propensity to let developers get away with murder and PowerVR's alternative of
punishing every missed step.
The test apps work okay with GLES or GLES2 as the renderer. For some reason
alpha blending doesn't seem to work on the Tegra 2; last week NVIDIA pushed out
a new set of X11 GLES drivers, so I'll try and investigate once I upgrade
those. Also, this patch adds things to configure.in, include/SDL_config.h.in
and test/configure.in. I didn't know what the policy was re. committing
generated spaghetti from autotools, so ./autogen.sh has to be run again. Sorry.
I think that's about everything, let me know if there's anything I've
overlooked.
The trick is that if you're using configure and you don't want to have SDL_config.h and SDL_revision.h to show up as modified, you need to configure and build from a separate directory.
You also need to include SDL_revision.h directly if you want to use the SDL_REVISION constant, as a side effect of these changes.
