gnome's gtkdoc function does not support content files which are
not strings. However, there are situations where files generated
by other targets might be needed.
Array options can receive duplicated values, which can produce
errors if case those duplicated values make processing some
elements twice when they are expected to be processed only once.
See issue #2762
Adds full_version to class Compiler. If set full_version will be printed
additionally.
Added support for CCompiler and CPPCompiler
Added support for gcc/g++, clang/clang++, icc.
If LLVM is built from a git mirror instead of from SVN it will have
"git-<very short sha>" at the end of the version. We need to remove that
so that version comparison will work correctly.
Fixes: #2786
* mesonbuild/modules/gnome.py (GnomeModule.compile_schemas): Allow the
depend_files kwarg.
* docs/markdown/Gnome-module.md: Add docs for new kwarg (and the only
other one that is permitted).
Using NotImplementedError throws an ugly traceback to the user which
does not print the line number and other information making it
impossible to figure out what's causing it.
Also override it for internal dependencies because self.name is "null"
for them.
The sysconfig config variables are different on MSYS2 and the paths
are also different. We now also use the full path to the import or
static library instead of using -Lfoo -lpython35 etc.
Also obey the value of the 'static' keyword argument.
sysconfig.get_platform() returns 'mingw' with MSYS2, so we need to
use some other method; in this case I chose to use the CC that
Python was compiled with, which is a relatively reliably indicator
unless people start using Python on Windows compiled with Clang or
something.
/usr/bin/env does not exist on Haiku since there's no /usr. The actual
location is /bin/env. Detect that case and directly use the
interpreter being passed to `env` in the shebang.
Also reorganize the Windows special cases which does the same thing.
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.
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.