Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
Commit a0cade8f introduced a typo and wrongly check for
gtk4-update-icon-cache twice.
If gtk4-update-icon-cache (gtk4) is not found, look for
gtk-update-icon-cache (gtk3) instead.
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...
We print a warning if a compilation database isn't successfully
generated, which is good, because that gives some visibility in case the
user really wanted to use the compdb. But warnings default to being
fatal with --fatal-meson-warnings, which is not so good, because this
isn't a very important warning at all, and we'd rather not error out in
such cases when building works fine and a random bonus IDE feature
doesn't work.
Mark this particular warning as non-fatal.
Fixes side issue in https://github.com/mesonbuild/wrapdb/pull/343#issuecomment-1074545609
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
It looks like internally we use pkgconfig, even though the installed
name is pkg-config. This fixes `tests cases/common/44 pkgconfig-gen`,
which will ignore PKG_CONFIG and select the wrong pkg-config binary if
you have $PKG_CONFIG set.
In the even that all of the inputs are generated, and they're all
generated into the same folder, and there are no subfolders, we would
fail to correctly handle all of the files after the main file. Let's fix
that.t
We currently don't handle subdirectories correctly in
structured_sources, which is problematic. To make this easier to handle
correctly, I've simply changed `structured_sources` to only use Files
and not strings as an implementation detail.
While gtk+-3.0 / gtk4 do exist, they have never provided the location of
the gtk-update-icon-cache program as a pkgconfig variable. Trying to
find one anyway, resulted in two things happening:
- a useless dep lookup
- a fatal-meson-warnings error and build failure because the
get_pkgconfig_variable() in question never existed
The desktop-file-utils package is a package solely providing some
command line programs, and has never provided a pkg-config file in the
first place, so this always logged that the dependency was not found and
fell back to normal find_program_impl(), although without
fatal-meson-warnings build errors.
Fixes#10139
The code in the C++ and Fortran compilers' language_stdlib_only_link_flags
method is broken and cannot possibly have ever worked. Instead of
splitting by line, it splits by whitespace and therefore, instead of
the last line of the compiler output:
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0
it is only the last field that has its first 11 characters removed.
Instead of reinventing the wheel with a new and brittle pattern,
reuse get_compiler_dirs.
Fixes: 64c267c49 ("compilers: Add default search path stdlib_only_link_flags", 2021-09-25)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When reverting from 0.62 to 0.59, one can see an error like this:
line 1003, in load
obj = pickle.load(f)
File "/Users/pm215/src/qemu-for-merges/meson/mesonbuild/mesonlib/universal.py",
line 2076, in __setstate__
self.__init__(**state) # type: ignore
TypeError: __init__() got an unexpected keyword argument 'module'
FAILED: build.ninja
Raise a MesonException for TypeError as well, so that reconfiguration
proceeds using cmd_line.txt.
It was originally added because proper detection was not working on
Debian, but that has been fixed since. It was causing annoying warning
by default when prefix is /usr/local that can only be avoided by setting
options.
This reverts commit 79c6075b56.
# Conflicts:
# docs/markdown/snippets/devenv.md
# mesonbuild/modules/python.py
# test cases/unit/91 devenv/test-devenv.py
PYTHONPATH cannot be reliably determined. The standard use case for
installing python modules with Meson is mixed pure sources (at least
`__init__.py`) and compiled extension_modules or configured files.
Unfortunately that doesn't actually work because python will not load
the same package hierarchy from two different directories, one a source
directory and one a (mandatory) out of tree build directory.
(It kind of can, but you need to do what this test case accidentally
stumbled upon, which is namespace packages. Namespace packages are a
very specific use case and you are NOT SUPPOSED to use them outside that
use case, so people are not going to use them just to circumvent Meson
devenv stuff as that would have negative install-time effects.)
Adding PYTHONPATH anyway will just lead to documentation commitments
which we cannot actually uphold, and confusing issues at time of use
because some imports *will* work... and some will *not*. The end result
will be a half-created tree of modules which just doesn't work together
at all, but because it partially works, users attempting to debug it
will spend time wondering why parts of it do import.
For any case where the automatic devenv would work correctly, it will
also work correctly to use `meson.add_devenv()` a single time, which is
very easy to manually get correct and doesn't provide any significant
value to automate.
In the long run, an uninstalled python package environment will require
"editable installs" support.
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".
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
Xavier Claessens
Eli Schwartz
Antoine Jacoutot
Tristan Partin
Hemmo Nieminen
Remi Thebault
Dylan Baker
Jussi Pakkanen
Paolo Bonzini
Ralf Gommers