This is a mixin class for DynamicLinkers that aims to provide only the
most basic posix-like linker arguments, in other words bits that gnu ld,
apple's ld, solaris's ld, and other completely disjoint linkers that are
used on Unix-like OSes share.
Ifort can generate dependency information (.d files), it just does it
differently than GNU compilers do. This also fixes a bug caused by
adding the dependency generation commands to the GNULike class later in
this series.
These two functions are different only in the classes that they use, a
couple of simple in-line ternaries takes care of that and reduces code
duplication.
Clang doesn't really like having no-undefined plus the address sanitizer, but
gcc doesn't mind. This all happens to work with clang + gnu ld, but with clang
+ apple ld this turns into a dumpster fire. Just add b_lundef=false to make
everyone happy.
the fact that foo and bar are not directories makes Apple's ld upset, and with
fatal warnings it dies on this test. Using real directories makes it happy.
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.
GLib does not currently use override_find_program() for this tool
because it is compiled and would not work in cross build. But this
prepares Meson for when/if GLib will rewrite it in Python.
See https://gitlab.gnome.org/GNOME/glib/issues/1859.
Build and target info is confusing in that case. However still log that
information, as it is useful in case something slips out of sync and
needs to be debugged.
'if_true' sources should be built with their dependencies, as
illustrated by test case change.
Ideally, I think we would want only the files with the dependencies to
be built with the flags, but that would probably change the way
sourceset are used.
This will allow using gtk-doc as a subproject instead of having to
install it on the system. It also has the side effect of failing at
configuration time with a proper message if gtkdoc is not installed,
instead of failing at build time with a python backtrace.
There are two variables that CMake takes into account during
find_package() in cross-compiled environments, which are: CMAKE_SYSROOT
and CMAKE_FIND_ROOT_PATH. Those are used in cmFindCommon::RerootPaths()
function, which blindly prepends all search paths with those specified
via CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH.
Extend search paths by using CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH in a
similar way as CMake does, so we successfully find CMake packages
information in cross-compiled environments.