The existing code broke create_project in ResidualVM, as
the loop that creates the actual build configurations
generated the hash from the actual object name, which
for ResidualVM would be XCConfigurationList_residualvm.
The same logic was not applied when generating the reference,
as that would use the hardcoded name XCConfigurationList_scummvm.
This patch makes a minimal fix for that, by using the
PROJECT_NAME define instead of the hardcoded name.
This is a workaround for the blurry display we get on retina screen
when building with SDK 10.14 or above. Unsetting the SDK version
in the executable is sufficient to avoid the issue. See bug
similar change in LibreOffice.
The workaround can only be used with Xcode 11 or above. When using
configure it automatically detects if the workaround can be used.
The workaround is disabled by default in create_project and needs
to be enabled manually (uncomment the MACOSX_NO_SDKVERSION define
at the top of the xcode.cpp file).
With the project including both iOS and macOS targets, using an
absolute path ensures it is incorrect for one of those. Since it was
using /usr/local/lib/ all the paths had to be changed in Xcode to
build the iOS target.
Also as the paths where we expect the libraries to be (/usr/local/lib
on macOS and lib under the build directory for iOS) are added to the
search path in the Xcode project, we do not actually need to use
absolute path). Also this make it easier to use a different path for
libraries (e.g. if using MacPort or brew) as we only need to change
the search path setting in the Xcode project and not the
path for each library).
The local documents are not currently internationalised simply
because the internationalised resources are not put into the right
places (NSBundle will handle this automatically when they are);
Trac#10464 is a tracking bug for this outstanding issue.
Fixes Trac#10437.
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.
