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 b926374205.
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.
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
Just like we automatically provide some reusable glue for self.static,
provide it here too. It seems plausibly like something people would
commonly want.
Both of these are artifacts of the time before Dependency Factories,
when a dependency that could be discovered multiple ways did ugly stuff
like finding a specific dependency, then replacing it's own attributes
with that dependency's attributes. We don't have cases of that left in
the tree, so let's get rid of this code too
This allow mypy to catch cases where we accidently assign the dependency
name to the type_name, as it sees them as having different types (though
at runtime they're all strings).
Eli Schwartz
Xavier Claessens
Dylan Baker
lilinzhe
Daniel Mensinger