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.
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.
Otherwise having an output directory matching the name of the cross file
in the current working directory will cause an error. This patch instead
collects any invalid names and prints them along with the error message
when no valid file can be found.
Fixes#5640
At configure time, kconfig can read from configure_file().
"test cases/kconfig/4 load_config builddir/meson.build" was already
showing a workaround, now it actually can take configure_file input
directly.
To make Fortran tests useful on Windows, the library_type should default to static,
unless needed to specifically test shared. Shared Fortran libs on Windows for
non-Gfortran compilers is fragile requiring proprietary code syntax.
Dylan Baker
Michael Hirsch, Ph.D
Xavier Claessens
John Ericson
James Hilliard
Jussi Pakkanen
Aleksey Gurtovoy
Jan Beich
Marc-André Lureau
Marcin Niestroj
Daniel Mensinger