So that every subclass doesn't have to reimplement it. Especially since
the Gnu implementation moved out of the CCompiler and into the
GnuLikeCompiler mixin
Every class needs to set this, so it should be part of the base. For
classes that require is_cross, the positional argument remains in their
signature. For those that don't, they just allow the base class to set
their value to it's default of False.
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
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
This should have worked before, but the inheritance order was backwards,
so we got the DCompiler before the GnuCompiler, and the base Compiler
methods overrode the Gnu methods.
DMD and LDC are a real pain to use as linkers. On Unices they invoke the C
compiler as the linker, just like meson does. This means we have to figure out
what C compiler they're using and try to pass valid arguments to that compiler
if the D compiler doesn't understand the linker arguments we want to pass. In
this case that means gcc or clang. We can use-the -Xcc to pass arguments
directly to the C compiler without dmd/ldc getting involved, so we'll use that.
This was never really true of the D compilers, it made them more
complicated than necessary and was incorrect in many cases. Removing it
causes no regressions on Linux, at least in our rather limited test
cases).
Since version 9.1, GCC provides support for the D programming language. Thus it
is easy to build a cross-compiler for D, such as aarch64-unknown-linux-gnu-gdc.
However to cross-compile a Meson project using D, using a cross build definition
such as the following is not enough:
```
[binaries]
d = '/path/to/aarch64-unknown-linux-gnu-gdc'
exe_wrapper = '/path/to/qemu-aarch64-static'
[properties]
needs_exe_wrapper = true
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'cortex-a53'
endian = 'little'
```
Indeed, "exe_wrapper" is not be taken into account. Build will fail with:
```
Executables created by D compiler /path/to/aarch64-uknown-linux-gnu-gdc are not runnable.
```
This patch fixes this by reworking:
- detect_d_compiler() to properly get exe_wrapper and D compilers and detect the
one available.
- Dcompiler to properly handle exe_wrapper.
These compilers invoke external linkers and have the appropriate .linker
property set. Therefore, BasicLinkerIsCompilerMixin appears to be
misplaced.
It used to work by chance, because BasicLinkerIsCompilerMixin failed to
override the get_allow_undefined_link_args method. The D compilers do
not provide their own get_allow_undefined_link_args, because they expect
to inherit it from Compiler, which simply delegates it to the linker.
Now that BasicLinkerIsCompilerMixin correctly overrides that method with
a stub, it broke compilers that relied on the buggy behavior.
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
We support 3 D compilers, DMD, LDC, and GDC. DMD is the reference
compiler, and LDC attempts to largely mirror it's command line usage.
GDC does not, it instead acts like GCC (which makes sense). The current
abstraction puts DMD behavior in the base D compiler and then overrides
then in the GnuDCompiler class.
This is messy, but it becomes more problematic when splitting the linker
and compiler abstractions apart.
I've opted to instead split the DCompiler class into two separate
classes. The DCompiler implements core D functinoality, and
DmdLikeCompilerMixin, which implements the DMD and LDC command line
arguments. I've then mxed that into the DmdDCompiler and LLVMDCompiler
classes, and mixed the GnuCompiler into the GnuDCompiler class to get
Gnu command line behavior.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
Because we need to inherit them in some cases, and python's
keyword-or-positional arguments make this really painful, especially
with inheritance. They do this in two ways:
1) If you want to intercept the arguments you need to check for both a
keyword and a positional argument, because you could get either. Then
you need to make sure that you only pass one of those down to the
next layer.
2) After you do that, if the layer below you decides to do the same
thing, but uses the other form (you used keyword by the lower level
uses positional or vice versa), then you'll get a TypeError since two
layers down got the argument as both a positional and a keyword.
All of this is bad. Fortunately python 3.x provides a mechanism to solve
this, keyword only arguments. These arguments cannot be based
positionally, the interpreter will give us an error in that case.
I have made a best effort to do this correctly, and I've verified it
with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm
and Elbrus that I don't have access to.
Currently, ComplierHolder.determine_args() unconditionally adds the link
arguments to the commmand, even if we aren't linking, because it doesn't
have access to the mode (preprocess, compile, link) that
_get_compiler_check_args() will use.
This leads to command lines like:
'cl testfile.c /nologo /showIncludes /c /Fooutput.obj /Od kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib comdlg32.lib advapi32.lib'
which clang-cl considers invalid; MSVS cl accepts this, ignoring the
unneeded libraries
Change from passing extra_args down to _get_compiler_check_args(), to
passing down a callback to CompilerHolder.determine_args() (with a bound
kwargs argument), so it can consult mode and kwargs to determine the args to
use.
Dylan Baker