D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Emscripten does have a stand alone linker, wasm-ld. This patch adds the
linker, adds detection for the linker, and removes the IsLinkerMixin for
emscripten. This is a little more correct, and makes the code a lot
cleaner and more robust.
This makes two basic changes, 1 it moves the name of the linker into the
linker class, this should reduce the number of errors and typos, and
ensure that a linker always has one name. This then renames the linkers
to have more consistent names.
Posix/gnu linkers are called ld.<name>: ld.gold, ld.lld, ld.solaris.
Apple linkers are renamed ld64.
These are pretty much all over the place because I never intended them
to be exposed to the meson source language, they were meant just for
documentation.
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