sdl2_frt/premake/README-linux.txt

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.
Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI(). 2015-06-21 17:33:46 +02:00			`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.`