Note that this still doesn't compile with the library package provided
by bSr43 because this package is missing libvorbisfile.a and has a
non standard name for libglib-2.0.a. But it would probably be better
to fix the package than maintain non-standard packages.
Starting in Xcode 8, clang reports warnings about singleton
instantiation which are noisy, so suppress these warnings for the
moment. An attempt to fix this properly was added in
eefa72afa1978a9dea10f5b1833fcc8f58a3468e but it was backed out in
940b2a20f1cd490afb6e541a3cd26f0d3bdd1687.
See https://github.com/scummvm/scummvm/pull/967 and
https://github.com/scummvm/scummvm/pull/994.
c19c10d548b2867bc4fd003fb29ac0017b2bd29d fixed the bad parsing of
module.mk which meant the Xcode generator broke. For the moment,
just move the hack for browser_osx.mm into the generator, until
there is a more elegant solution to this problem (if ever).
FluidSynth does build and run successfully, but it is necessary
to get the correct static libraries. It can be manually built
against dylib, if desired, by manually adding the fluidsynth.dylib
to the Frameworks. Since this will result in a runtime dependency,
this is not set up by default.
Libraries were being included unconditionally regardless of the
arguments passed to create_project, and in the case of macOS were
being added using manual linker flags and other such hacks instead
of using the Frameworks list.
Formerly we relied on static linkage. However, in the presense of modern
OpenGL (ES) implementations it is not easily identifable which library to link
against. For example, on Linux amd64 with nVidia drivers and SDL2 setup to
create a GLES 1.1 context one would need to link against libGL.so. However,
traditionally GLES 1.1 required to link against libGLESv1_CM.so. To prevent a
huge mess we simply resolve the OpenGL functions on run-time now and stop
linking against a static library (in most cases).
GLES support needs to be enabled manually on configure time for now.
Tizen changes have NOT been tested.
