[quake3-commits] [ioquake/ioq3] 071965: Makefile: confine $(LIB) to the one platform that ...

[Tim Angus]

  Branch: refs/heads/master
  Home:   https://github.com/ioquake/ioq3
  Commit: 071965b3f0647385f3c32a49c1df5e125550969c
      https://github.com/ioquake/ioq3/commit/071965b3f0647385f3c32a49c1df5e125550969c
  Author: Simon McVittie <smcv at debian.org>
  Date:   2015-07-14 (Tue, 14 Jul 2015)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  Makefile: confine $(LIB) to the one platform that needs it, namely irix64

It isn't mentioned anywhere else, and deleting it from the Linux code
path means we don't need to maintain an exhaustive list of 64-bit
architectures.


  Commit: c91fab3900345d047f085d1e467521bba1ebd28f
      https://github.com/ioquake/ioq3/commit/c91fab3900345d047f085d1e467521bba1ebd28f
  Author: Simon McVittie <smcv at debian.org>
  Date:   2015-07-14 (Tue, 14 Jul 2015)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  build: canonicalize all ARM variants to "arm", matching q_platform.h

The ARCH in the Makefile must match the ARCH_STRING in q_platform.h;
otherwise, ioquake3 will install (for instance) uiARCH.so but look for
uiARCH_STRING.so, which isn't going to go well (particularly for
the modular renderer).

Like i386, but unlike most (all?) other Linux platforms, uname -m on
32-bit ARM machines can have various results starting with "arm",
depending on the specific CPU version (e.g. Raspberry Pi is armv6l,
RPi2 is armv7l). Again similar to the x86 family,
it's appropriate for them to share an architecture suffix;
q_platform.h has traditionally used "arm" so let's use that.

64-bit ARM makes a clean break from this, much like 64-bit x86 does:
uname -m produces a string not starting with arm (specifically
"aarch64"), and gcc predefines __aarch64__ instead of __arm__.
As a result, it is unaffected by this change.


  Commit: 2a71948f21fe588dbce9b29409283e9c912ef8e7
      https://github.com/ioquake/ioq3/commit/2a71948f21fe588dbce9b29409283e9c912ef8e7
  Author: Simon McVittie <smcv at debian.org>
  Date:   2015-07-14 (Tue, 14 Jul 2015)

  Changed paths:
    M Makefile
    M code/qcommon/q_platform.h

  Log Message:
  -----------
  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.


  Commit: 61a49ba1dbe0fb61b3674b9f38e282f0e2aa51ab
      https://github.com/ioquake/ioq3/commit/61a49ba1dbe0fb61b3674b9f38e282f0e2aa51ab
  Author: Tim Angus <tim at ngus.net>
  Date:   2015-07-15 (Wed, 15 Jul 2015)

  Changed paths:
    M Makefile
    M code/qcommon/q_platform.h

  Log Message:
  -----------
  Merge pull request #129 from smcv/generic-platform

Implement Linux architecture support generically


Compare: https://github.com/ioquake/ioq3/compare/c91fe0bcfef6...61a49ba1dbe0