OpenAL's pkg-config database doesn't list include/AL as a location for
AL headers, but including <AL/al.h> is unusable because some systems
store the headers in OpenAL instead of AL. So check if the file can
actually be found as <al.h> and amend the include directory list
otherwise.
CMake 3.1's if() by default now interprets quoted variable names as
strings. This is a good idea from a strictness perspective, so make it
do this even if we're in 2.8.9 compatibility mode.
Auto-detecting UPnP might fail when CMake was invoked multiple times.
This would result in a broken build because the compiler would not find
<natupnp.h>.
There's no point in splitting the audio library selection into multiple
CPP macros, since there can always only be one anyway. Merge all of them
into a single macro AUDIO_TK (for "toolkit") and have CMake select one
for the user, instead of making him choose (and potentially failing).
If pkg-config does not exist on the build system, then the old
FindFreetype.cmake behavior will be fallen back upon, but pkg-config
should be a lot more reliable.
As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
Since FindFreetype.cmake already extracts the version of freetype
from its header files, I have no idea why they're not automatically
using that info to look for the proper library name in lieu of
hardcoding a single version.
Earlier versions of ld(1) would attempt to implicitly satisfy link requirements
by checking the dependencies of linked-in libraries. Current versions don't do
this anymore, so we need to explicitly spell out all dependent libraries on the
linker command line.
Nicolas Hake