Age | Commit message (Collapse) | Author | Files | Lines |
|
We currently cannot make this work because inside dependency() we don't
know the current subproject. We would also like the optional but
extremely useful location node, but we don't have that either...
Convert the broken code to a FIXME for visibility.
|
|
On Windows using MSYS2 MinGW installing the package `mingw-w64-x86_64-wxmsw3.1` provides `wx-config-3.1`. I have tried building my software by making this exact change and it build correctly.
|
|
This is gross and looks terrible, but I'm not entirely sure how else to
do this.
And cmake is an inferior methodology, TBH, since it is effectively the
same as our own builtins. However, cmake also handles some bizarre
Windows library names whose provenance I'm not entirely sure of, in
addition to implementing the usual excessive pattern of hardcoded search
directories. So, this may be useful, at least on Windows, as a fallback.
(I am not really interested in offering feature compatibility with cmake
for a bunch of bizarre naming schemes that ***aren't the official cmake
library names***, so if cmake allows that and people really feel they
need it, all the more power to them.)
Nevertheless, I believe if it got found via our system dependency class,
it will always provide results which are just as functional as cmake.
cmake can only find openssl installations that would otherwise be
missed.
This also avoids the case where users did
```
dependency('OpenSSL', modules: [...], method: 'cmake')
```
and expected it to work, since our builtin dependency supersedes the
divergent case and didn't previously allow the cmake method. I don't
know why they would do such a thing, but who knows... it is always
possible.
|
|
On some platforms, this is provided by the base system, which
nevertheless refrains from providing the .pc files that go along with
it. As a result, it's impossible to sensibly find these dependencies.
I'm looking at you, FreeBSD...
Upstream tracking bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659
This is also a problem on macOS, but that's unfixable (and I believe
they provide some truly ancient and out-of-support version anyway) and
you probably want to use the homebrew OpenSSL. Still, meson can now
detect these old versions and even set their version number.
|
|
|
|
|
|
|
|
And one undefined T.cast name in a file that isn't yet mypy-ready
anyway.
|
|
|
|
gnome points out that CustomTargets can be linked with, so we should
allow that.
|
|
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
|
|
|
|
|
|
|
|
In 1fb6c939473ca7cdab2 the intl dep gained support for static linking
which also forwarded this property to the iconv sub dependency.
The refactoring in 214d03568f75 lost this change, which results in
iconv getting linked dynamically again.
Forward static again to fix this.
|
|
This also includes some refactoring, since the alternaticve would
have been to duplicate the huge traceparser target code block again.
fixes #9581
|
|
has_function(prefix: '...') is useless to check the difference between
builtins and external library functions. It has code to detect
"builtins" that misfires and reports that iconv_open is defined as a
builtin on mingw, but only if you include the header.
Instead compile an open-coded test file that this iconv dependency
implementation fully controls, that doesn't get up to imaginative edge
cases like trying to find `__builtin_iconv_open`.
Fixes commit db1fa702f3943c6e4fec142b2bf5468c89173993, which merely
moved the brokenness over one step to the right (by breaking mingw
instead of freebsd)
Fixes https://github.com/mesonbuild/meson/pull/9632#issuecomment-979581509
|
|
This header is required anyway. And the compile test for linking to libc
with the iconv_open symbol, can succeed when we try to use the literal
symbol name without includes, but fail later during project build,
because actually including iconv.h might redefine the function to match
a forked symbol. This happens when GNU iconv is installed as a
standalone library on systems that have a less fully-featured iconv
implementation.
So, by including the header in has_function, we ensure that we test
against the default resolved header. In the event that the symbol which
is #define'd by the header is 'libiconv_open', linking will fail against
libc even when a builtin iconv does exist, and we will fall back to the
iconv dependency that provides -liconv (and which is needed to properly
use the default header).
Fixes compiling against the iconv dependency on e.g. FreeBSD when the
libiconv port is installed.
|
|
Contrary to most system method checks, zlib currently functions as a
whitelist of OSes. This isn't really needed however. The first special
case for OSes that provide zlib as part of the base OS is worth keeping.
However, the elif for windows is more than generic enough to allow any
other potential OSes to try. Just make it a simplie if/else instead.
|
|
Convert bare library names to a dependency linker argument using
find_library(), rather than hardcoding the MSVC transformation.
|
|
Depending on whether hdf5 is compiled with parallel support, the
same config-tool program may be installed with a mysterious "p" in the
name. In this case, dependency lookup will totally fail, unless of
course you use the superior pkg-config interface in which case you get a
predictable name.
Work around this insanity by checking for both types of config-tool
name.
Fixes #9555
|
|
The same method that the BSDs use should also work for android. Also
update the tests and docs where appropriate.
|
|
|
|
|
|
The dep.name() function schould always return the name of the
dependency as documented. No matter if it was found or not.
https://mesonbuild.com/Reference-manual_returned_dep.html#depfound
|
|
|
|
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
|
|
|
|
CMakes `target_link_libraries()` supports certain keywords to
only enable specific libraries for specific CMake configurations.
We now try our best to replicate this for Meson dependencies.
Fixes #9197
|
|
|
|
|
|
Since typing != T as far as flake8 is aware, give the linter an extra
hint.
|
|
|
|
'{}'.format('foo') for any given value of 'foo' (in this case, a
function returning a string), can always just be 'foo' directly, which
is a lot more readable.
|
|
All changes were created by running
"pyupgrade --py3-only"
and committing the results. Although this has been performed in the
past, newer versions of pyupgrade can automatically catch more
opportunities, notably list comprehensions can use generators instead,
in the following cases:
- unpacking into function arguments as function(*generator)
- unpacking into assignments of the form x, y = generator
- as the argument to some builtin functions such as min/max/sorted
Also catch a few creeping cases of new code added using older styles.
|
|
Handle is_sunos() machines in __machine_info_to_platform_include_dir
|
|
|
|
Also internally needed by intl, so add that as a proxied dependency
instead of coding it manually.
|
|
|
|
Dependencies are currently printed as
[<mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeac70>, ' ', <mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeab50>]
This was introduced in commit adb1b2f3f6ad54b346348ec6e5b8d96f2f7ba0a6, due to
an incorrect type annotation on the AnsiText constructor. Fix both the
annotation and the usage.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
|
|
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
|
|
This boolean parameter is added to check_and_set_roots() and detect_lib_dirs()
when true it will first search the compiler library directories before checking
the standard lib directories. This is set to false when using BOOST_ROOT and
set to true when useing other system directories like /usr/local
Also simplify using a set to remove duplicate lib files
Also remove the part where you search the Cellar in homebrew, this is
unnescessary now that symlinks can be followed it should find boost
when searching /usr/local so no need to search the Cellar
|
|
|
|
This does two things:
* allows the library files to be symlinks
* searches `lib` and `lib64` in `BOOST_ROOT` even if it finds lib
directories from the compiler
The first condition is needed for the homebrew on macOS because boost and boost
python are provided in seperate packages and are put together in /usr/local/lib
with symlinks to the library files. The both conditions are needed for high
performace computing environments where dependencies are often provided in
nonstandard directories with symlinks
A test case was added which looks for boost libraries in seperate directories
which have been symlinked to BOOST_ROOT/lib
|
|
GTestDependencySystem (and other similar dep classes) sets
self.is_found=True, but the version check could still fail. In the case
the dependency is not required `ExternalDependency._check_version()`
won't raise an exception and thus the dependency is accepted.
_check_version() sets self.is_found() in the case self.version is not
empty, we should do it too when self.version is empty.
Fixes: #9036.
|
|
Since intl links internally to iconv, try to pull in iconv too, but only
if we specifically ask for static libs.
If PREFER_SHARED, we have no way to tell which type we got, so do not
try handling that...
|
|
Although find_library returns the library as a list of args, has_header
returns a tuple(is_found, is_cached) which is non-empty and thus always
true. Which is confusing...
Check whether it actually got found.
|