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>
Deal with clang-cl doing the sane (but different to MSVC) thing, of
generating an empty import library, rather than silently ignoring
/IMPLIB when there are no exports.
It's a (presumably unintentional) quirk of the current implementation of
SharedLibrary.determine_filenames() that if both name_suffix and
name_prefix are set, an import library isn't generated.
Adjust test 'common/25 library versions': Make the library have exports,
so an implib is generated with MSVC. Add implib to set of files expected
to be installed
Adjust test 'common/122 shared module': Add libnosyms implib to set of
files expected to be installed, except for MSVC, where none is generated
as it has no exports
Extend platform_fix_name() to handle this case
We avoid using library(version:), so we don't have to teach
platform_fix_name() all the platform details of versioned shared library
naming. Hopefully that's exercised by platform-specific tests...
Use the specified name_prefix for implib, rather than hardcoding it.
(This is needed to allow an installed library given name_prefix:'' and a
name starting with 'lib' to be linked with using -l. (This case is
handled specially in the pkgconfig module))
as instructed in the python docs, you should not use PIPE here. This can
lead to deadlocks, with massive testsuite output. Which was the case for efl.
For now the output of the tests is redirected into the a temp file, the
content from there can then be used to fill the TestRun structure.
This fixes test running problems in efl.
Add Windows SDK tools to PATH (for rc). This requires INCLUDE to be set.
lld-link doesn't seem to default to searching the correct directories, so
LIB needs to be set.
The easiest way to get the correct setting of INLCUDE and LIB env vars seems
to be to import the VS env vars, then revert the PATH.
'test cases/common/123 llvm ir and assembly' requires ML/ML64 (masm) on
Windows. If we are using clang-cl, that might not be available, so skip
test in that case.
Dylan Baker
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
Olivier Crête
Jon Turney
Luca Weiss
Marcel Hollerbach