Since the last appveyor image update which also included a msys2 update
test_meson_installed() fails for the msys2 mingw jobs complaining that
the install path isn't included in PYTHONPATH.
It complains that "site-packages\" isn't included in "site-packages" ignoring
that the separator should be ignored here. Work around the issue by making
sure that the path set as PYTHONPATH always ends with os.sep.
Because we need to inherit them in some cases, and python's
keyword-or-positional arguments make this really painful, especially
with inheritance. They do this in two ways:
1) If you want to intercept the arguments you need to check for both a
keyword and a positional argument, because you could get either. Then
you need to make sure that you only pass one of those down to the
next layer.
2) After you do that, if the layer below you decides to do the same
thing, but uses the other form (you used keyword by the lower level
uses positional or vice versa), then you'll get a TypeError since two
layers down got the argument as both a positional and a keyword.
All of this is bad. Fortunately python 3.x provides a mechanism to solve
this, keyword only arguments. These arguments cannot be based
positionally, the interpreter will give us an error in that case.
I have made a best effort to do this correctly, and I've verified it
with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm
and Elbrus that I don't have access to.
samu prints a different message when the build is a no-op, so make
assertBuildIsNoop consider that as well.
Also, if compile_commands.json cannot be found, just skip the test. This
seems reasonable since meson just produces a warning if `ninja -t compdb`
fails.
Finally, only capture stdout in run_meson_command_tests.py, since the
backend may print messages the tests don't recognize to stderr.
Fixes#3405.
Resolves segfaults on i686 kernel. Also execute all available simd
instructions, not just the best one.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Signed-off-by: Michael Hudson <michael.hudson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894774
This makes it clear in the results that tests marked "should_fail"
exist. We also avoid the all caps output and make the classifications
unambigous compared to pytest or autotools' XFAIL/XPASS.
Before:
OK: 329
FAIL: 1
SKIP: 0
TIMEOUT: 0
After:
Ok: 323
Expected Fail: 1
Fail: 6
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Because we are racing here. In reality *all* of the java in that target
may rely on the generated file, so we need to block all of them, like we
would for headers in C/C++.
It is similar to --reconfigure but completely wipe the build directory
first. It is intended to make easier to rebuild project when builddir somehow
got corrupted.
Fixes#3542.
Write command line options into a separate file to be able to
reconfigure from scatch in the case coredata cannot be loaded. The most
common case is when we are reconfiguring with a newer meson version.
This means that we should try as much as possible to maintain backward
compatibility for the cmd_line.txt file format.
The main difference with a normal reconfigure is it will use new
default options values and will read again environment variables like
CFLAGS, etc.
When trying to cross-compile mesa on an aarch64 system, I noticed some
strange behavior. Meson would only ever find the wayland-scanner binary
in my host machine's sysroot (/mnt/amethyst):
Native dependency wayland-scanner found: YES 1.16.0
Program /mnt/amethyst/usr/bin/wayland-scanner found: YES (/mnt/amethyst/usr/bin/wayland-scanner)
It should be finding /usr/bin/wayland-scanner instead, since the
wayland-scanner dependency is created as native. On closer inspection,
it turned out that meson was ignoring the native argument passed to
dependency(), and wuld always use the pkgconfig binary specified in my
toolchain instead of the native one (/usr/bin/pkg-config):
Native dependency wayland-scanner found: YES 1.16.0
Called `/home/lyudess/Projects/panfrost/scripts/amethyst-pkg-config
--variable=wayland_scanner wayland-scanner` -> 0
Turns out that if we create a dependency() object with native:false, we
end up caching the pkg-config path for the host machine in
PkgConfigDependency.class_pkgbin, instead of the build machine's
pkg-config path. This results causing in all pkg-config invocations for
dependency() objects to use the host machine's pkg-config binary,
regardless of whether or not 'native: true' was specified when the
dependency() object was instantiated.
So, fix this by never setting PkgConfigDependency.class_pkgbin for cross
dependency() objects. Also, add some test cases for this. Since
triggering this bug can be avoided by creating a dependency() objects
with native:true before creating any with native:false, we make sure
that our test has two modes: one where it starts with a native
dependency first, and another where it starts with a cross dependency
first.
As a final note here: We currently skip this test on windows, because
windows doesn't support directly executing python scripts as
executables: something that we need in order to point pkgconfig to a
wrapper script that sets the PKG_CONFIG_LIBDIR env appropriately before
calling pkg-config.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
Dylan Baker
Christoph Reiter
Jon Turney
Kayla Ngan
Mathieu Duponchelle
Nirbheek Chauhan
Stian Selnes
Michael Forney
Jussi Pakkanen
Dimitri John Ledkov
Xavier Claessens
Dave Reisner
Phillip Cao
Lyude Paul
John Ericson