| Age | Commit message (Collapse) | Author |
|
It's now only used to populate the DependencyCandidate, so we can remove
it and just calculate the same information from the `type_name`
parameter. This reduces code and the number of method calls.
|
|
It's allowed in the `DependencyKeywordArguments` TypeDict already, so we
now have two sources of truth. Additionally, it's often populated by
reading from that dict, so we're just doing useless work.
|
|
So we don't create a default name that is overwritten except in the case
of appleframeworks. This allows for some cleanup, including
deleting some initializers that were only setting the name.
|
|
This is really class constant for all dependencies, and by taking it out
of the initializer we make the `__init__` call have a more consistent
interface.
|
|
|
|
This allows us to check that all of the keyword arguments are of the
correct type.
|
|
The two methods are identical.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add `extra_paths` to cache keys for `PkgConfigInterface`
and `PkgConfigCLI` instances, to avoid incorrectly reusing an instance
with a different `extra_paths` value, see:
https://github.com/mesonbuild/meson/pull/14657#discussion_r2320623799
Signed-off-by: Michał Górny <mgorny@quansight.com>
|
|
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Michał Górny <mgorny@quansight.com>
|
|
|
|
|
|
Prepend the path of uninstalled libraries to PKG_CONFIG_PATH
so they have preference over other search paths set by the
user.
see: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
|
|
This ensures that we are not modifying lists from lru cache.
|
|
|
|
|
|
While at it, make more methods private by storing the version found on
the instance. That avoids having to call check_pkgconfig() as static
method from unittests.
|
|
|
|
|
|
Make sure that pkgconfig_define is a pair of strings and not a list with
more than 2 strings.
|
|
This is our standard annotation policy, and makes mypy safe under python
3.7
|
|
This makes the code cleaner and will allow to have other implementations
in the future.
|
|
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.
|
|
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
EnvironmentVariables was always broken, it used MutableMapping because
everyone <3 abstract interfaces, especially when they are broken and
don't actually do what you want.
This needs a dict interface, exposing `.copy()`. We either use a dict or
os._Environ, and the latter also supports that.
Also fix a broken import, and the fallout from forgetting to update the
signature of self.envvars in commit b926374205bd761085031755c87152d08bc10e9d.
|
|
If `pkg-config --modversion foobar` fails, we don't know why. The
general issue here, though, is that call_pkgbin routinely logs stdout
for informational purposes, but not stderr.
Fixes #11076
|
|
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
|
|
It doesn't really need class instantiation to just know what type it is,
and this way we can get the information early if a dependency fails to
init.
|
|
dependencies: allow get_variable to expose files from subprojects
|
|
The new get_env() method that returns an EnvironmentVariables object
will be needed in next commit that will pass it to CustomTarget.
This has the side effect to use the proper os specific path separator
instead of hardcoding `:`. It is the obvious right thing to do here, but
has caused issues in the past. Hopefully issues have been fixed in the
meantime. If not, better deal with fallouts than keep doing the wrong
thing forever.
|
|
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
|
|
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
|
|
|
|
|
|
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
|
|
|
|
This is broken and terrible and thus completely unusable. Don't torture
users by finding pkg-config on Windows, thus permitting the pkg-config
lookup of several dependencies that do not actually work -- which then
fails at build time.
This also breaks CI for the wrapdb, because Strawberry Perl is provided
as part of the base image for the OS (yes, even though it is terribly
broken!!!) and anything that depends on e.g. zlib will "find" zlib
because of this broken disaster, even though it should use the wrapdb
subproject of zlib.
It is assumed no one actually wants to mix Strawberry Perl and meson. In
fact, some projects, such as gst-build, already unconditionally error
out if Strawberry Perl is detected in PATH:
error('You have Strawberry Perl in PATH which is known to cause build issues with gst-build. Please remove it from PATH or uninstall it.')
Other projects (postgresql) actually do want to build perl extensions,
and link to the perl dlls, but absolutely under no circumstances ever
want to use its pkg-config implementation. ;)
Let's solve this problem by just considering this to not be a valid
pkg-config, let the user find another or not have one at all.
This change "solves"
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11
|
|
There are a bunch of cases in a single function where we would want to
log the detected path of pkg-config. Formatting this is awkward. Define
it once, then use f-strings everywhere. :D
|
|
and clean up all outstanding issues
Skip 'test cases/common/141 special characters/meson.build' since it
intentionally uses trailing newlines.
|
|
fixs: #9000 Meson not correctly process with -l:xxx.a link arguments in pkgconfig .pc file.
see also:https://stackoverflow.com/questions/48532868/gcc-library-option-with-a-colon-llibevent-a
with unit test, unit test will be partially skiped if pkg-config version < 0.28 .
see: https://gitlab.freedesktop.org/pkg-config/pkg-config/-/blob/master/NEWS
|
|
Just like we automatically provide some reusable glue for self.static,
provide it here too. It seems plausibly like something people would
commonly want.
|