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
This already reports the location (in a slightly different format), but
using mlog.warning() will make it easier if we want to change the location
format in future.
If a dep is not found on the system and a fallback is specified, we
have two cases:
1. Look for the dependency in a pre-initialized subproject
2. Initialize the subproject and look for the dependency
Both these require version comparing, ensuring the fetched variable
is a dependency, and printing a success message, erroring out, etc.
Now we share the relevant code instead of duplicating it. It already
diverged, so this is a good thing.
As a side-effect, we now log fallback dependencies in the same format
as system dependencies:
Dependency libva found: YES
Dependency libva found: YES (cached)
Dependency glib-2.0 from subproject subprojects/glib found: YES
Dependency glib-2.0 from subproject subprojects/glib found: YES (cached)
Otherwise we will try to use the objc compiler when linking projects
with both objc and C++.
Technically we should use the objc++ linker when doing this, but on
most (all?) systems the objc++ linker is `c++`, which is the same
as the C++ linker.
Closes https://github.com/mesonbuild/meson/issues/2468
The Visual Studio Developer Command Prompt always sets the VSINSTALLDIR
environment variable. If not, we probably have a broken environment and
won't get very far anyway.