aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/dependencies
AgeCommit message (Collapse)AuthorFilesLines
2022-04-12qt dependency: adapt to the qmake command changed nameEli Schwartz1-1/+1
Qt now has official guidance for the symlinked names of the tools, which is great. Qt now officially calls the tools `fooX` instead of `foo-qtX` where the major version of Qt is X. Which is not great, because a bit of an unofficial standard had prior art and now needs to change, and we never adapted. Prefer the official name whenever looking up qmake, and in the testsuite, specifically look only for the official name on versions of qt which we know should have that.
2022-04-12qt dependency: find the correct -qtX configtool nameEli Schwartz1-1/+2
Fixes regression in commit c211fea51389728783cf59ae41156a5e0de9c41a. The original dependency lookup looked for `qmake-{self.name}`, i.e. `qmake-qt5`, but when porting to config-tool, it got switched to `qmake-{self.qtname}` i.e. `qmake-Qt6`, which was bogus and never worked. As a result, if `qmake-qt5` and `qmake` both existed, and the latter was NOT qt5, it would only try the less preferred name, and then fail. We need to define self.name early enough to define the configtool names, which means we need to set it before running the configtool __init__() even though configtool/pkgconfig would also set it to the same value. Mark the tests as passing on two distros that were failing to detect qmake due to this issue, and were marked for skipping because we assumed that the CI skipping there was an expected case rather than an old regression.
2022-04-12Add support for Qt 6.1+John Lindgren1-0/+9
Qt 6.1 moved the location of some binaries from QT_HOST_BINS to QT_HOST_LIBEXECS as noted in the changelog: c515ee178f Move build tools to libexec instead of the bin dir - Tools that are called by the build system and are unlikely to be called by the user are now installed to the libexec directory. https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/6.1.0/release-note.txt It's possible to help the 'qt' module find the tools by adding Qt's libexec directory to the PATH environment variable, but this manual workaround is not ideal. To compensate, meson now needs to look for moc, rcc, uic, etc. in QT_HOST_LIBEXECS as well as QT_HOST_BINS. Co-authored-by: Stefan Hajnoczi <stefanha@jammr.net>
2022-04-12cmake: Always use all compilers for LLVM (fixes #10249)Daniel Mensinger3-4/+14
2022-03-29move a bunch of imports into TYPE_CHECKING blocksEli Schwartz1-2/+3
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.
2022-03-23boost: preserve compiler/linker argument orderHemmo Nieminen1-2/+2
Looks like boost dependency mixes up it's compiler and linker argument order when it is removing duplicates (?) from those. This causes unnecessary recompilations of everything depending on those components. Use OrderedSet to remove the duplicates while also maintaining consistent order for them.
2022-03-23Fix DUB dependenciesRemi Thebault1-126/+295
- fix the research of target built by DUB - explicitely state that DUB dynamic libraries and source libraries are not supported (yet) (mesonbuild#6581) - fix the build settings of recipes having sub-dependencies (mesonbuild#7560) - fix winlibs added from dub recipe - sanitization, comments, explanations...
2022-03-13Merge pull request #9339 from dcbaker/submit/structured_sourcesJussi Pakkanen1-3/+6
Structured Sources
2022-03-07move a bunch of imports into TYPE_CHECKING blocksEli Schwartz1-1/+3
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.
2022-03-07treewide: string-quote the first argument to T.castEli Schwartz2-4/+4
Using future annotations, type annotations become strings at runtime and don't impact performance. This is not possible to do with T.cast though, because it is a function argument instead of an annotation. Quote the type argument everywhere in order to have the same effect as future annotations. This also allows linters to better detect in some cases that a given import is typing-only.
2022-03-07merge various TYPE_CHECKING blocks into oneEli Schwartz1-5/+3
A bunch of files have several T.TYPE_CHECKING blocks that each do some things which could just as well be done once, with a single `if` statement. Make them do so.
2022-03-07dependencies: Dependency Sources can be StructuredSourcesDylan Baker1-3/+6
2022-03-07Merge pull request #9743 from mensinda/cmakeGeneratorFixedJussi Pakkanen1-2/+2
cmake: Add TARGET_ generator expression support (fixes #9305)
2022-03-04Add modules kwarg to JNI system depTristan Partin1-3/+58
This allows someone to link against libjvm.so and libjawt.so.
2022-03-03add D features to InternalDependencyRemi Thebault1-2/+9
2022-03-02Rename JDK system dep to JNITristan Partin2-4/+20
JNI is a more apt name because it currently only supports the JNI. I also believe that CMake uses the terminology JNI here as well. JNI is currently the only way to interact with the JVM through native code, but there is a project called "Project Panama" which aims to be another way for native code to interact with the JVM.
2022-03-01cheat and evade the detection of "open()" in custom_lintEli Schwartz1-6/+6
It's a dumb check which doesn't know the difference between python functions and string data. Work around this by changing the message output to not include an opening parenthesis, and changing other similar strings the same way for consistency.
2022-03-01mark a bunch of dependencies with the version they were introducedEli Schwartz2-0/+7
All these dependencies are impossible to find on versions of Meson older than the ones they got custom lookups in, because they don't provide pkg-config files. So they should not / cannot be reasonably used on older versions, and it is easy to say "yep, these should emit a FeatureNew for the versions they got added in".
2022-03-01allow dependency checks to bubble up feature warnings to the interpreterEli Schwartz1-0/+3
It would be too difficult and probably a layering violation to give an interpreter handle to the inner guts of every dependency. What we can do instead is let every dependency track: - the Feature checks it can produce, - the version attribute for when it was implemented while leaving the interpreter in charge of actually emitting them.
2022-02-17intl dependency: include header when checking for libc builtinEli Schwartz1-1/+2
This header is required anyway. And the compile test for linking to libc with the gettext symbol, can succeed when we try to use the literal symbol name without includes, but fail later during project build, because actually including libintl.h might redefine the function to match a forked symbol. This happens when GNU libintl is installed as a standalone library on systems that have a less fully-featured gettext implementation. So, by including the header in has_function, we can ensure that we test against the default resolved header. In the event that the symbol which is #define'd by the header is 'libintl_gettext', linking will fail against libc even when a builtin gettext does exist, and we will fall back to the intl dependency that provides -lintl (and which is needed to properly use the default header). Of course, even that probably won't work. has_function(prefix: '...') is useless to check the difference between builtins and external library functions. It has code to detect "builtins" that misfires in some cases (previously seen with iconv_open). Instead compile an open-coded test file that this intl dependency implementation fully controls, that doesn't get up to imaginative edge cases like trying to find `__builtin_gettext`. It's the only way to be sure. Fixes compiling against the intl dependency on e.g. Alpine Linux when the libintl package is installed.
2022-02-16flake8: fix wrong numbers of blank line separatorsEli Schwartz1-1/+0
2022-02-16flake8: fix typoed whitespace surrounding tokensEli Schwartz1-1/+1
2022-02-14comment out broken Feature checks that fail mypyEli Schwartz1-3/+10
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.
2022-02-14Add wx-config-3.1 provided by mingw-w64-x86_64-wxmsw3.1apoorv5691-1/+1
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.
2022-02-02openssl dependency: add cmake supportEli Schwartz2-4/+11
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.
2022-02-02dependencies: add a system dependency for OpenSSLEli Schwartz2-1/+71
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.
2022-02-01new custom dependency lookup for libdlAndrew Krasavin2-0/+28
2022-02-01Fix dep.get_variable() with empty string default_valueXavier Claessens1-1/+1
2022-01-27flake8: fix indentation styleEli Schwartz2-2/+2
2022-01-27fix some flake8 violations for unused importsEli Schwartz1-1/+1
And one undefined T.cast name in a file that isn't yet mypy-ready anyway.
2022-01-23cmake: Add TARGET_ generator expression support (fixes #9305)Daniel Mensinger1-2/+2
2022-01-18dependencies: fix libraries and whole_libraries typesDylan Baker1-4/+5
gnome points out that CustomTargets can be linked with, so we should allow that.
2022-01-18dependencies: don't pass kwargs from get_pkgconfig_variableDylan Baker4-28/+23
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
2022-01-10port from embedded data to importlib.resourcesEli Schwartz2-2/+2
2022-01-10pyupgrade --py37-plusEli Schwartz1-1/+1
2021-12-17Fix mypy errorsDaniel Mensinger1-2/+2
2021-12-12intl dep: forward static to iconv if neededChristoph Reiter1-1/+1
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.
2021-12-01cmake: Fix old style dependency lookup with imported targetsDaniel Mensinger1-91/+17
This also includes some refactoring, since the alternaticve would have been to duplicate the huge traceparser target code block again. fixes #9581
2021-11-28iconv dependency: try even harder to find working iconvEli Schwartz1-1/+2
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
2021-11-25iconv dependency: include header when checking for libc builtinEli Schwartz1-1/+1
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.
2021-11-20dependencies/zlib: Allow for generic OS checksDudemanguy1-4/+1
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.
2021-11-20cmake: Use find_library() on bare library names in cmake dependenciesJon Turney1-6/+4
Convert bare library names to a dependency linker argument using find_library(), rather than hardcoding the MSVC transformation.
2021-11-17hdf5 dependency: check for alternative config-tool namesEli Schwartz1-3/+3
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
2021-11-15dependencies/zlib: Add system zlib method for androidDudemanguy1-2/+2
The same method that the BSDs use should also work for android. Also update the tests and docs where appropriate.
2021-11-01various manual conversion of percent-formatted strings to f-stringsEli Schwartz3-18/+14
2021-10-27fix various flake8 whitespace errorsEli Schwartz2-2/+2
2021-10-26dep.name(): return dependency name even if dependency is not foundThomas Heijligen2-3/+3
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
2021-10-24cmake: Add support for the Linux CMake registry (fixes #9418)Daniel Mensinger1-0/+6
2021-10-10pkg-config: do not ever successfully detect Strawberry Perl.Eli Schwartz1-0/+4
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
2021-10-10simplify some log formatting by splitting out a commonly used format stringEli Schwartz1-5/+4
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
generated by cgit v1.1 at 2025-03-25 12:37:57 +0000