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.
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.
Fixes regression in commit c211fea513. 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.
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>
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.
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.
- 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...
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.
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.
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.
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.
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.
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".
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.
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.
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.
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 1fb6c93947 the intl dep gained support for static linking
which also forwarded this property to the iconv sub dependency.
The refactoring in 214d03568f lost this change, which results in
iconv getting linked dynamically again.
Forward static again to fix this.
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 db1fa702f3, 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.
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
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
Xavier Claessens
Eli Schwartz
John Lindgren
Daniel Mensinger
Hemmo Nieminen
Remi Thebault
Dylan Baker
Tristan Partin
apoorv569
Andrew Krasavin
Christoph Reiter
Dudemanguy
Jon Turney
Thomas Heijligen
Christian Clauss