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.
