Adding the current subdir when extracting resources deps wasn't good,
it is CustomTarget job to handle that.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Currently only not found deps implicitly pulled from a Library object
are ignored. We should also ignore not found deps passed directly to
generate() method.
This makes the unit testing more complicated because libfoo pkgconfig
dependency cannot be found when generated from the within the same
meson.build.
This replaces calls to .rstrip('git'), .rstrip('svn') with a regex that
takes the leading numbers and dots, and throws away the rest. This also
moves the code up to the ConfigToolDepdency level, since these config
tools are of various quality and some of them are good, and some are
not. This shouldn't affect well behaved tools.
This should future proof LLVM against future suffixes (like someone
doing something strange like using Mercurial as a VCS).
I'm not sure this is a good idea, but at the moment it seems a bit too easy
to write something like dep.get_pkgconfig_variable('inculdedir:') (sic) and
not notice it's not doing anything useful.
The output may be a binary data stream, not subject to any locale
encoding. This avoids any encoding errors that might arise as a result.
Also fixes github issue #2868.
This is important so people can not trick Meson to select a
subproject_dir that is not in the project's source directory.
It also ensures a string is used for the path.
They now are published by the D Language Foundation, and not Digital
Mars. Therefore, their signature has changed slightly.
(We can not check for 'DMD', because that string appears in every
compiler version output to denote the frontend version used by the
compiler).
The previous change disallowed any subdirectories for subproject dirs,
and therefore broke a couple of projects making use of that.
This change still prevents people from setting subproject dirs that are
not in the project's source tree, while allowing to specify any path
within the project's directory again.
Resolves: #2719
Because FreeBSD's llvm-config adds -l/usr/lib/libexecinfo.so when asked
for system-libs, which is bogus. We'll remove the leading -l from any
argument that also ends with .so.
gnome.gtkdoc uses -Wl,-rpath to ensure the scanner executable built by
gtkdoc-scangobj will load shared libraries from the correct directories.
However, FreeBSD configures its linker to use --enable-new-dtags by
default, which converts RPATH to RUNPATH. If users have LD_LIBRARY_PATH
environment variable set, RUNPATH will be overrided by LD_LIBRARY_PATH
and libraries will be loaded from wrong directories, causing undefined
symbol error when running the executable.
In order to solve the problem, we have to prepend directories specified
with -Wl,-rpath to LD_LIBRARY_PATH to avoid relying on the deprecated
RPATH attribute.
The reason for this change is the same as the previous commit. Although
g-ir-scanner can pick arguments from CFLAGS, CPPFLAGS, LDFLAGS
environment variables by itself, it is still better for build systems
to put them on the command line instead of relying on users to setup
the same environment.
Since g-ir-scanner doesn't provide a way to set arbitrary linker flags
on the command line, arguments in LDFLAGS that are not started with -L
are not passed.
GLib-based libraries and applications require gettext library to compile
and link. On non-GNU systems such as FreeBSD, gettext is not included in
libc and it is required to pass '-L/usr/local/lib -lintl' to the linker
to satisfy the dependency on gettext. The pkg-config file provided by
GLib already has '-lintl', but users still have to remember to put
'-L/usr/local/lib' into LDFLAGS. If we don't pass LDFLAGS to
gtkdoc-scangobj, the linker will not be able to find '-lintl' when no
dependencies of the project provides '-L/usr/local/lib'.
Since all *FLAGS are commonly used in many build systems, this commit
adds support for not only LDFLAGS but also CFLAGS and CPPFLAGS.
Fixes#1724
teach detect_meson_py_location() that meson.py is not the
only one meson executable (there's wraptool + legacy scripts)
that could be installed to the PATH folder
fixes#2810