The MinGW toolchain can read MinGW paths, but Python cannot and we
sometimes need to parse the libs and cflags manually (for static-only
library searching, for instance). The MinGW toolchain can always read
Windows paths with `/` as path separater, so just use that.
The .a library was being built with `ar` which is not the right
static archiver, it's supposed to be something like
x86_64-w64-mingw32-ar or whatever the target-triple is.
Try using the built-in static linker detection instead of doing it
manually.
Also try harder to find a compiler that dependencies can use.
This means that in C++-only projects we will use the C++ compiler for
compiler checks, which can be important.
We can't know if the .lib is a static or import library, but that's
a problem in general too. The only way to figure out if a specific
file is an import or a static library is to dump its symbols and check
if it starts with __imp or not.
Even then, some libs are hybrid import and static, i.e., they contain
references to DLLs for some symbols and also provide implementations
for other symbols so this is a difficult problem.
Closes https://github.com/mesonbuild/meson/issues/2659
MSVC cannot handle MinGW-esque /c/foo paths, convert them to C:/foo.
We cannot resolve other paths starting with / like /home/foo so leave
them as-is so the user gets an error/warning from the compiler/linker.
These paths are commonly found in pkg-config files generated using
Autotools inside MinGW/MSYS and MinGW/MSYS2 environments.
Currently this is only done for PkgConfigDependency.
As the Vala compiler does not define thread_flags() and
thread_link_flags(), depending on threads in any capacity will cause Meson to
fail.
Fixes#2720.
The test used by the new define_variable parameter was using the
includedir directory. However, in order to get a successful test,
the includedir variables needs to be relative to the prefix
variable, otherwise the replacemente will not have any effect.
This changes uses the prefix variable itself because we can
assure that it will be present.
One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
'test cases/frameworks/9 wxwidgets' fails to build with clang on
Fedora because it needs C++11 enabled.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
When `ninja -C builddir/ test` is run, ninja will change into the build
dir before starting, but `meson test -C builddir/` does not. This is
important because meson does not use (for good reasons) absolute paths,
which means if a test case needs to be passed as an argument a file name
that is part of the build process, it will be relative builddir. Without
changing into the builddir the path will not exist (or worse, point at
the wrong thing), and test will not behave as intended.
To fix this mtest will change directory before starting tests, and will
change back after all tests have been finished.
Fixes#2710
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.
While finding an external program, we should only split the shebang
once since that is what Linux and BSD also do. This is also why
everyone uses #!/usr/bin/env in their shebangs since that allows
you to run an interpreter in a path with spaces in it.
See `man execve` for more details, specifically the sections for
interpreter scripts.
Depending on the tool (moc, uic, rcc, lrelease), the Qt version
(4.8, 5.7, 5.9) and the distribution (Fedora, debian,...) it seems you
cannot predict which of -v or -version will be supported.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Currently passing a bad combo or array option, providing a non-boolean
to a bool arg, or a host of other things can cause an traceback from a
MesonException, don't do that.
Fixes#2683
Joergen Ibsen
Niklas Claesson
Jussi Pakkanen
Nirbheek Chauhan
Ernestas Kulik
Iñigo Martínez
Dylan Baker
Alexis Jeandet
Solomon Choina
Zbigniew Jędrzejewski-Szmek
Patrick Griffis