summaryrefslogtreecommitdiff
path: root/src/tools
diff options
context:
space:
mode:
authorSimon McVittie <smcv@debian.org>2015-07-14 22:51:57 +0100
committerTim Angus <tim@ngus.net>2016-04-07 11:02:31 +0100
commitf0e19948fe871198ea9c049f721ab2caf458bcb7 (patch)
treea311cb4d5c2fbcb6c8b9595e117d95fa29146c04 /src/tools
parent3711115ee2d393b3fc3b7ef744803ca41ecc2ac6 (diff)
build: define ARCH_STRING in Makefile on Linux and other GNU platforms
GNU platforms (Linux, kFreeBSD, Hurd) have endian.h to determine endianness, so all architectures except x86_64 are in fact treated identically, except that their ARCH_STRING is different. The ARCH_STRING must always be identical to the ARCH from the Makefile, otherwise the engine will not find its cgame, game and ui plugins under their expected names and startup will fail. If we pass it in from the Makefile, then an identical value is guaranteed, and we can get rid of an increasingly long list of defined(__some_cpu__) tests. The one remaining quirk is that we test __x86_64__ to determine whether to define idx64; I've kept that, but separated it from the ARCH_STRING. On non-Linux platforms we only support a few architectures anyway, so keeping the list up to date is less of a burden; *BSD porters could probably use the same technique to get support for lots of architectures with little effort, but I have not done that here, because I cannot test it. Windows must continue to support preprocessor-based architecture tests in any case, so that the MSVC solutions (which do not use the Makefile) can continue to work. However, Windows only runs on a few CPU families, so this shouldn't be a significant burden in practice. When cross-compiling, the tools are compiled for the build architecture (COMPILE_PLATFORM, COMPILE_ARCH) rather than the host architecture (PLATFORM, ARCH), so define ARCH_STRING to COMPILE_ARCH on a GNU COMPILE_PLATFORM.
Diffstat (limited to 'src/tools')
0 files changed, 0 insertions, 0 deletions