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.
D compilers are configured to have highest priority when chosing linker
for targets mixing C/C++/D code and before this change meson would fail
to configure gtest target that uses D library as a dependency.
* Enums are strongly typed and make the whole
`gcc_type`/`clang_type`/`icc_type` distinction
redundant.
* Enums also allow extending via member functions,
which makes the code more generalisable.
We now use the soversion to set compatibility_version and
current_version by default. This is the only sane thing we can do by
default because of the restrictions on the values that can be used for
compatibility and current version.
Users can override this value with the `darwin_versions:` kwarg, which
can be a single value or a two-element list of values. The first one
is the compatibility version and the second is the current version.
Fixes https://github.com/mesonbuild/meson/issues/3555
Fixes https://github.com/mesonbuild/meson/issues/1451
fixes#4032: meson now checks properly for the compiler used to compile dub dependencies
fixes#3568: applied the following patch https://paste.debian.net/1039317/
meson now adds flags for native dependencies required by dub modules
meson now checks for the D version implemented by the compiler used to build dub dependencies (execpt gdc which doesn't support this)
Daniel Mensinger