Added Ben Henning's GSoC2013 work: premake build system.

premake/README-linux.txt

@@ -0,0 +1,46 @@
+You may generate GNU makefiles for building SDL2 and its related test suite by
+using the gmake shell script in the Linux/build-scripts folder.
+
+Linux support is currently experimental for the meta-build system. Most of the
+progress made on this support happened toward the end of the meta-build system
+project, so there is a lot currently missing that could be added in the future.
+For the most part, the Linux support works well, but there is a significant
+amount of testing needed to verify it can be built in many different
+environments.
+
+The Linux project does not target every dependency it should (as seen in the
+autotools configure script or in the CMake script), but it does target the
+following dependencies:
+
+  -D-Bus (required to build Linux at all)
+  -DLOpen (most of the other dependencies are dependent on this)
+  -ALSA
+  -PulseAudio
+  -ESD
+  -NAS
+  -OSS
+  -X11
+  -OpenGL
+
+Also, the Linux system should be building the SDL2 library as a shared library,
+but it builds it as a static library because of a few premake-related issues.
+This is because when the makefile generated by premake tells the linker where to
+find the definitions library (libSDL2.o), it also gives a hint to the loader to
+find libSDL2.so in the same place, with a relative path. This means in order to
+execute the program dynamically linked to SDL2, it's looking in some path like:
+
+  "../../SDL2/Build/Debug"
+
+Now, while this path works at the location of the makefile (such as
+./tests/testsprite), it does not make sense from the actual location of the
+executable (./tests/testsprite/Build/Debug). Furthermore, it's just massively
+inconvenient to have a relative path to look for the shared object. Moving
+libSDL2.so into the same directory as the executable does not solve this issue.
+Unfortunately, premake also does not allow an install target to be created for
+the makefiles, which is another one of the major issues related to building SDL2
+as a shared library on Linux. Once these problems are solved, this support
+should be very straightforward to add to this system in the future.
+
+The Linux system does have both an automated test and cleaning shell files for
+running through the entire supported test suite and cleaning up the generated
+and built files, respectively.