Dependencies in the "if_true" keyword argument do not prevent the
sources from being used; in other words, they work just like dependencies
with "disabler: false".
However, this was broken in commit ab0ffc6a2 ("modules/sourceset: Fix
remaining typing issues", 2022-02-23) which changed logic instead of
just fixing typing issues. This was likely an attempt to avoid using
"dependencies.Dependency" after the "dependencies" field was declared,
but it also broke QEMU.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The dependencies field clashes with the dependencies module, so that
mypy interprets "dependencies.Dependency" as a "Dependency" attribute
of the "dependencies" field.
Rename the field to something else, so that it does not clash.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In commit 68e684d51f the _get_link_args
function was modified from returning a list[str] of arguments, to a
tuple of both that and a modified copy of the entire target's
current/enhanced dependencies (why not just the new ones? I don't know).
However, the existing use of the function was not adapted to this
change, and tried to turn this entire tuple into a node of the command
line. Tuples cannot flatten to lists, and mesonlib.File or
HoldableObjects don't make good command line arguments.
As a result we errored out with:
ERROR: Argument (['-L/path/to/builddir/', '--extra-library=foo'], [<SharedLibrary 25a6634@@foo@sha: foo>, <SharedLibrary 25a6634@@foo@sha: foo>, <SharedLibrary 25a6634@@foo@sha: foo>]) in "command" is invalid
Split out the flags and the dependencies and update the former while
replacing the latter.
In this case, the test fname might have an implicit extension and cannot
be found by `os.path.isfile()`.
We cannot use `shutil.which()` to handle platform differences, because
not all test fnames are executable -- for example Java jars.
The test representation does have an "is built" attribute which in
theory should work here, because all built targets definitely have their
full filename known to Meson, but it turns out to be misnamed. Rename it
correctly and add an actual "is built" attribute to check.
Tests which aren't built by Meson can be assumed to exist without
consulting their existence on the filesystem.
Fixes#10027
We need this for the python module, as implemented in commit
e8375d20a9, but that then crashed in
subprojects because those options were never forwarded to the subproject
interpreter.
We are supposed to fallback on the fallback when running the vcstagger,
but instead we errored out during configure.
Fixes regression in commit b402817fb6.
Before this, we used shutil.which || relative paths, and in the latter
case if it could not be found we still wrote out that path but it failed
to run in vcstagger. Now, we use find_program under the hood, so it
needs to be run in non-fatal mode, and if it is not found, we simply
keep the original command string. It's a VCS command, so if we magically
end up finding it at runtime because it was installed after running
configure, that is *fine*.
In commit c88bfdbefc we added support for
an exe_wrapper to gtkdoc, which checked twice whether the environment
says it is needed, and didn't check at all whether one was provided.
The result:
File "/usr/lib/python3/dist-packages/mesonbuild/modules/gnome.py", line 1354, in gtkdoc
t_args.append('--run=' + ' '.join(state.environment.get_exe_wrapper().get_command()))
AttributeError: 'NoneType' object has no attribute 'get_command'
Instead, check whether we have a valid exe_wrapper (if we don't need
one, then even when one is defined in the cross file, we get an
EmptyExternalProgram) and if we do, use it.
If we don't have one, but need one, then we revert back to the behavior
before commit c88bfdbefc, which probably
means "executing the doc target causes the command to error out with
"Exec format error".
The regex in question causes Python's regex parser to freeze
indefinitely in certain Python versions. That might be due
to a bug or because the re does infinite backtracking and it just
happened to work on earlier implementations.
It used to be possible to do this:
```
bomb = find_program('nonexisting', required: false)
test('traceback during meson test', bomb)
```
and it would in fact bomb out, with:
```
[0/1] Running all tests.
Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 149, in run
return options.run_func(options)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 2017, in run
return th.doit()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1685, in doit
runners.extend(self.get_test_runner(test) for test in tests)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1685, in <genexpr>
runners.extend(self.get_test_runner(test) for test in tests)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1586, in get_test_runner
return SingleTestRunner(test, env, name, options)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1308, in __init__
self.cmd = self._get_cmd()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1374, in _get_cmd
test_cmd = self._get_test_cmd()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1352, in _get_test_cmd
if self.options.no_rebuild and not os.path.isfile(testentry):
File "/usr/lib/python3.10/genericpath.py", line 30, in isfile
st = os.stat(path)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
```
This is something we explicitly check for elsewhere, for example when
using a not-found program as a command in a custom target or generator.
Check for it when making a test too, and error out with a similar error.
Fixes#10091
This reverts commit e257a870fe.
The PR adding this command had infinitely hanging CI, and now that it is
merged to master we cannot get any CI on any PR to succeed.
There are two cases where we can assume we found the python dependency
with its requisite libraries using sysconfig:
- we found the library with find_library and are prepared to link to it
- the library is not actually part of the dependency, so its presence or
absence is irrelevant
In the latter case, we should consider it found if link_libpython is
False. Originally we did this, but the logic was inverted in commit
5b422fce87 in an unrelated change and
without explanation, likely by accident.
Normally this doesn't much matter, since a python invariably comes with
a predictably located libpython and the first condition evaluates true.
But that is not true for pypy, and in fact that is the reason the
link_libpython check was originally added in commit
1bd14b52b2.
Restore that original logic.
Fixes#8570
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.
It is often useful to check the found version of a program without
checking whether you can successfully find
`find_program('foo', required: false, version: '>=XXX')`
Disabling targets because the tools used to build them aren't available
is a pretty suspicious thing to do. Users who want this are probably, in
general, advised to check themselves whether it is possible to build
those targets with find_program(..., required: false)
The i18n.gettext() invocation is a bit unusual because the product of
running it is non-critical files, specifically, translation catalogs. If
users don't have the tools needed to build them, they may not be able to
use them either, because perhaps they have NLS disabled on their
platform or it's difficult to put it in the bootstrap path.
So, for this reason, it was made non-fatal and the message catalogs are
just not created, and the resulting build is still perfectly usable
*unless* you want to use it in another language, at which point it
"works" but the text is all inscrutable to the end user, and that's a
feature of the target platform.
That's an acceptable tradeoff for translation catalogs.
It is NOT an acceptable tradeoff for merge_file, which produces desktop
files or MIME database catalogs or other files which have crucial roles
to perform, without which the software in question simply doesn't work
at all. In such cases, this just fails to install crucial files, users
report bugs to the project in question, and the project adds
`find_program('xgettext')` to guarantee the hard error due to lack of
confidence in Meson.
Fixes#6165Fixes#8436
Paolo Bonzini
Eli Schwartz
Jussi Pakkanen
Ralf Gommers
Tristan Partin
Xavier Claessens
Marvin Scholz
Dylan Baker