The fix for Requires generation in #3406 missed a second code path with the same
problem.
Passing a pkgconfig dependency to requires would produce Q, t, 5, C, o,r, e'
instead of 'Qt5Core'.
This was introduced in 8efd940.
Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
It is weird and inconsistent to have different pc file depending on
default_library value when using library() or build_target(). We should
skip dependencies only when user explicitly want shared library only.
Whilst working on the Reproducible Builds effort [0], we noticed
that meson creates non-reproducible pkgconfig files as it relies
on Python set ordering.
This was originally filed in Debian as #892515 [1].
[0] https://reproducible-builds.org/
[1] https://bugs.debian.org/892515
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.
Special case ThreadDependency by taking compiler's flags and
PkgConfigDependency by adding them in requires(.private) instead. For
other Dependency objects just take their link_args and compile_args.
Closes#2725
The install_dir parameter of the libraries can also contain the
prefix path, which creates wrong library paths in the .pc file.
This patch detects if prefix is contained in the library path
and creates a relative path.
Fixes#2469
Without specifying a custom install directory string, get_custom_install_dir() returns True. So for the `Libs` entry I was getting this:
Libs: -L${prefix}/True -lfoo
Now it behaves as expected:
Libs: -L${libdir} -lfoo
This also adds a "# noqa: F401" comment on an unused "import lzma",
which we are using it in a try/except block that is being used to
check if the lzma module is importable; of course it is unused.
v2: This turned out to be a little tricky.
mesonbuild/modules/__init__.py had the "unused" import:
from ..interpreterbase import permittedKwargs, noKwargs
However, that meant that the various modules could do things like:
from . import noKwargs # "." is "mesonbuild.modules"
Which breaks when you remove __init__.py's "unused" import. I
could have tagged that import with "# noqa: F401", but instead I
chose to have each of the module import directly from
"..interpreterbase" instead of ".".
Usage:
pkgconfig.generate(
...
description : 'A library with custom variables.',
variables : ['foo=bar', 'datadir=${prefix}/data']
)
The variables 'prefix', 'libdir' and 'includedir' are reserved, meson will
fail with an error message.
Variables can reference each other with the pkgconfig notation, e.g.
variables : ['datadir=${prefix}/data',
'otherdatadir=${datadir}/other']
meson does not check this for correctness or that the referenced variable
exists, we merely keep the same order as specified.
You can now pass a list of strings to the install_dir: kwarg to
build_target and custom_target.
Custom Targets:
===============
Allows you to specify the installation directory for each
corresponding output. For example:
custom_target('different-install-dirs',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : ['somedir', 'otherdir])
This would install first.file to somedir and second.file to otherdir.
If only one install_dir is provided, all outputs are installed there
(same behaviour as before).
To only install some outputs, pass `false` for the outputs that you
don't want installed. For example:
custom_target('only-install-second',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : [false, 'otherdir])
This would install second.file to otherdir and not install first.file.
Build Targets:
==============
With build_target() (which includes executable(), library(), etc),
usually there is only one primary output. However some types of
targets have multiple outputs.
For example, while generating Vala libraries, valac also generates
a header and a .vapi file both of which often need to be installed.
This allows you to specify installation directories for those too.
# This will only install the library (same as before)
shared_library('somevalalib', 'somesource.vala',
...
install : true)
# This will install the library, the header, and the vapi into the
# respective directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : ['libdir', 'incdir', 'vapidir'])
# This will install the library into the default libdir and
# everything else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [true, 'incdir', 'vapidir'])
# This will NOT install the library, and will install everything
# else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [false, 'incdir', 'vapidir'])
true/false can also be used for secondary outputs in the same way.
Valac can also generate a GIR file for libraries when the `vala_gir:`
keyword argument is passed to library(). In that case, `install_dir:`
must be given a list with four elements, one for each output.
Includes tests for all these.
Closes https://github.com/mesonbuild/meson/issues/705
Closes https://github.com/mesonbuild/meson/issues/891
Closes https://github.com/mesonbuild/meson/issues/892
Closes https://github.com/mesonbuild/meson/issues/1178
Closes https://github.com/mesonbuild/meson/issues/1193