Whilst working on the Reproducible Builds effort, we noticed that
meson was generates .pkgconfig files that are not reproducible.
For example, here is neatvnc's pkgconfig file when built with HEAD^1:
Name: neatvnc
Description: A Neat VNC server library
Version: 0.7.0
-Requires.private: pixman-1, aml < 0.4.0, aml >= 0.3.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
+Requires.private: pixman-1, aml >= 0.3.0, aml < 0.4.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
Libs: -L${libdir} -lneatvnc
Libs.private: -lm
Cflags: -I${includedir}
This is, ultimately, due to iterating over the contents of a set within a
DefaultDict and can thus be fixed by sorting the output immediately prior to
generating the Requires.private string.
An alternative solution would be to place the sorted(…) call a few lines
down:
return ', '.join(sorted(result))
However, this changes the expected ordering of the entire line, and many users
may be unhappy with that (alternative) change as a result. By contrast, this
commit will only enforce an ordering when there are multiple version
requirements (eg. a lower and a higher version requirement, ie. a version
range). It will, additionally, order them with the lower part of the range
first.
This was originally filed (with a slightly different patch) by myself in
the the Debian bug tracker <https://bugs.debian.org/1056117>.
Signed-off-by: Chris Lamb <lamby@debian.org>
When the pkgconfig module is imported, but not used, it will insert None
on the end of the devenv list. This list is not expected to contain
None, and causes Meson to crash. This can happen in complex build setups
(reported from mesa), where pkgconfig is only used in some
configurations
Fixes: #12032
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
We can check something's subtype using properties, without importing the
module up front and doing isinstance checks on specific subclasses of
the interface -- or worse, solving cyclic imports by doing the import
inside the function. ;)
msetup.py doesn't need to know the gory details of PkgConfigDependency,
or directly import it at program startup. It's also slightly wasteful to
generate a devenv for the -uninstalled directory when a project doesn't
even, in the end, use the pkgconfig module anyway.
If the optional first "mainlib" argument is there, then we infer several
values. Otherwise, some of those values fall back to a generic default,
and two of them -- name and description -- fall back to being mandatory.
In commit e84f293f67, we removed
validation for description as part of refactoring that never actually
validated anything.
The name can be None if a library is not passed as a positional
argument, and the name keyword argument is not provided. We shouldn't
allow that to happen.
There are still a lot of errors here due to a mixture of really bad
design (adding extra attributes to objects), and legitimate type errors
(passing a str where a List[str] is expected). I suspect a lot of these
cases aren't hit for some reason.
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
For the same reasons commit 7aa28456d ("Add dependency type for
Valgrind") removed linking with valgrind, pkgconfig shouldn't generate
"Requirements" for it, in general.
This solves dbus meson port question/issue from:
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/303#note_1444819
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
At several points in the code base, f-strings are not correctly expanded
due to missing 'f' string prefix. This fixes all the occurrences I could
find.
If set to true it will generate the pkgconfig files as relocatable i.e
the prefix variable will be relative to the install_dir. By default
this is false.
Will generate a MesonException if the pkgconfig file is installed
outside of the package and pkgconfig.relocatable=true.
Automatically generate additional variables and write them into the
generated pkg-config file.
This means projects no longer need to manually define the ones they
use, which is annoying for dataonly usages (it used to forbid setting
the base library-relevant "reserved" ones, and now allows it only for
dataonly. But it's bloat to manualy list them anyway).
It also fixes a regression in commit
248e6cf473 which caused libdir to not be
set, and to be unsettable, if the pkg-config file has no libraries but
uses the ${libdir} expansion in a custom variable. This could be
considered likely a case for dataonly, but it's not guaranteed.
When generating pkgconfig file for a library that links to an
uninstalled static library built by custom_target() Meson was crashing
when trying to access some attributes that does not exist on that class.
Also fix is_internal() implementation, it only really make sense on a
CustomTargetIndex or if CustomTarget has only a single output.
For example the OpenRC build files install libraries to install_dir: '/lib'
and this works, but causes the generated pkg-config to say:
prefix=/usr
Libs: -L${prefix}//lib
which is both ugly (double //) and resolves to /usr/lib which is exactly
what does not work.
This does not convert the build side, or remove any of the checking it
does. We still need that for other callers of custom target. What we'll
do for those is add an internal interface that defaults things, then
we'll be able to have those callers do their own validation, and the
CustomTarget validation machinary can be removed.
Fixes#9096
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
This commit introduces a new type of `HoldableObject`: The
`SecondLevelHolder`. The primary purpose of this class is
to handle cases where two (or more) `HoldableObject`s are
stored at the same time (with one default object). The
best (and currently only) example here is the `BothLibraries`
class.
We need to escape space in variables that gets into cflags or libs
because otherwise we cannot split compiler args when paths contains
spaces. But custom variables are unlikely to be path that gets used in
cflags/libs, and escaping them cause regression in GStreamer that use
space as separator in a list variable.