this can be useful for if/elif where linker behaviors must be
considered.
For example, clang with "link" vs gcc with "ld.bfd" etc.
ci for compiler.get_linker_id() method
doc
add @FeatureNew check
Co-Authored-By: Daniel Mensinger <daniel@mensinger-ka.de>
I originally liked "solaris", but I've changed my mind. Both illumos
(the open-source fork of OpenSolaris) and Oracle's closed-source
Solaris are identified by the same token, and there are differences
between them; so using "sunos" as a sort "supertype" for both makes
sense to me.
* c_function_attributes: remove 'protected' from 'visibility'
This doesn't exist on macos with the apple compiler, which always causes
failures.
Fixes#5530
* compilers: Add split visibility checks to has_function_attribute
These check for a single visibility at a time, rather than all four at
once. This allows for finer grained searches, and should make using
these checks safer across operating systems.
Because the Intel compiler behaves significantly differently on windows
than it does on Linux and MacOS I've decided it would be better to
follow the clang/clang-cl split and make id "intel-cl" on windows
(leaving "intel" alone on Linux and Mac). Since we've never supported
ICL and it hasn't worked in the past I think this is an okay change to
make.
Some compilers try very had to pretend they're another compiler (ICC
pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang
behaves much like GCC, but now also has clang-cl, which behaves like MSVC.
This method provides an easy way to determine whether testing for MSVC
like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to
succeed, without having to check for dozens of compilers and the host
operating system, (as you would otherwise have to do with ICC).
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
Niklas Hambüchen