Autotools will add endianess to the name of the architecture in some
cases (such as ppc64le vs ppc64) meson doesn't do this. It's worth
noting this in the documentation.
It's fairly common on Linux and *BSD platforms to check for these
attributes existence, so it makes sense to me to have this checking
build into meson itself. Autotools also has a builtin for handling
these, and by building them in we can short circuit cases that we know
that these don't exist (MSVC).
Additionally this adds support for two common MSVC __declspec
attributes, dllimport and dllexport. This implements the declspec
version (even though GCC has an __attribute__ version that both it and
clang support), since GCC and Clang support the MSVC version as well.
Thus it seems reasonable to assume that most projects will use the
__declspec version over teh __attribute__ version.
Instead of exposing the endianness in the CPU family, canonicalise the CPU
family to just "ppc64" to match MIPS (which is also bi-endian).
Part of the work for #3842.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
Nirbheek Chauhan
Dylan Baker
Alexey Brodkin
Jussi Pakkanen
Khem Raj
Ross Burton
Vasu Penugonda
Ross Burton
makise-homura
Somasekhar Penugonda
Tim Ansell
Hylke Bons
xknight
Jon Turney