Forced explicit linking against OpenAL

[takenu]

While trying to use tiny-game-engine in a more lightweight terrain generator I discovered that it is not possible to use tiny-game-engine without also separately linking against OpenAL, even if sound is not desired for the application.

I would like to suggest the following:

• either (1) link the OpenAL library into tiny-game-engine, if tiny-game-engine wants OpenAL to be present no matter what, so that the OpenAL functions are also present in the libtinygame.a object file,
• or (2) leave the choice of whether or not to use OpenAL to the user, and make sure that OpenAL is not called by internal tiny-game-engine functions, but only by the user (so that linking against tiny-game-engine does not result in linking errors).

[takenu]

The characterization of the problem is not very clear so let me point out what exactly I mean:

When making a SDLApplication object, for e.g. rendering stuff and interacting with key input through SDL, OpenAL stuff happens too. While key input and rendering is indeed kind of elementary, I doubt whether OpenAL is so indispensible. (Note by the way that we actually use OpenAL Soft, the free software library.)

Also, on a related note, I believe libtinygame should include the OpenGL and SDL (and maybe GLEW?) libraries that its SDLApplication uses. This would reduce the number of external libraries that the user of the library needs to link against.

[BasFaggingerAuer]

I agree that the number of external dependencies should be as small as possible and only consist of libraries that are readily available in common distro repositories. However, including the source code of all included libraries would defeat the purpose of the packages-with-dependencies-based architecture on which most linux distros are based and bloat the code significantly. (Not to mention that any updates to said libraries need to be manually added.)

Isolating audio support in the engine from the rest is a good idea though.

[takenu]

Well it's not about the source code, it's about linking the binary. When compiling libtinygame you should definitely link against the library object files, but when linking libtinygame as a library that is no longer necessary.

There are two ways of letting someone use a library like tiny-game-library:

1. provide a complete standalone package where any function defined by the engine can be called by the user, and
2. provide a minimal standalone package that must be re-linked by the user against all tiny-game-engine engine dependencies before any functions can be called. This is what tiny-game-engine currently does.

If someone compiles tiny-game-engine himself, then the two methods are equivalent and the only difference is that the user has to include all the dependencies twice: first when compiling tiny-game-engine, and then when compiling his own application.

If, however, someone acquires a binary form of tiny-game-engine precompiled for his system, then he can in principle skip a lot of dependency management if tiny-game-engine would follow strategy 1.

In getting tiny-game-engine to work on my laptop (running a somewhat outdated but still supported Ubuntu 12.04) I needed a lot of ppa-magic to compile everything (e.g. assimp was quite the challenge). If tiny-game-engine would follow strategy 1, only one developer could compile a binary for 12.04 that could then be used by anyone, and no one would have to use obscure ppa's for anything (not to mention that changes in e.g. CMakeLists.txt are often required for such ppa-originated libraries to be found). That does appear to make tiny-game-engine easier to use.

TL;DR: a larger libtinygame should be easier-to-use because the end user doesn't need to re-include dependencies.