Additional include and library directories can now be added.
This is most useful to Xcode Mac projects where a vanilla Homebrew setup
requires manually adding five directories through the Xcode UI and then
repeating that every time the project needs to be regenerated.
Now create_project can be scripted to regenerate a working Mac project
without any extra Xcode steps.
Non POSIX.1-2008 systems will not necessarily accept NULL as the
second argument, and could crash the program here. Provide a
temporary buffer on the stack instead, and don't count on realpath()
allocating one on the heap. This will work on older POSIX.1-2001
systems.
(In theory, this older POSIX.1-2001 syntax could have portability
problems too, because of PATH_MAX, but in practice this shouldn't
be a problem for the systems intended to be used by create_project.)
Fixes the build on Mac OS X Leopard.
Commit a1d930209a6452649ab704dbbcf2084c9177936e is actually enough to
stop the blurry display issue on Retina screens (Bug #11430).
This reverts most of 70f79d3df8b4a9d4c6d1b69838ff5a722c51b61e.
Different platforms have different levels of support of encodings and
often have slight variations. We already have tables for most encoding
with only CJK missing. Full transcoding inclusion allows us to get reliable
encoding results independently of platform. The biggest con is the need for
external tables encoding.dat.
It removes a duplicate table for korean in graphics/korfont.cpp
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).
