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.
If you rely on PKG_CONFIG_PATH to make anything work (like nixos) then
these tests cannot pass without the system values appended to the
override values.
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
Apparently Azure provides 64-bit python2 when we try to test 32-bit, and
that breaks everything on the 32-bit test runner.
I don't understand the environment setup, and that runner is
disappearing soon anyway. Hopefully this shuts up the known breakage.
Perhaps when this test case was originally created, project tests could
not use a matrix of options? This is certainly possible today, so don't
write special unittest handling for this instead.
This adds proper visibility into what gets run and what doesn't. Now we
know which python executables got tested and which got skipped.
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*.
Xavier Claessens
Hemmo Nieminen
Remi Thebault
Eli Schwartz
rusty-snake
Dylan Baker
Tristan Partin
Jussi Pakkanen
Paolo Bonzini
Ralf Gommers