This move the sorting logic into the TestDef class itself, which
simplifies sorting them.
Additionally it remove overcomplicated sort logic, because python
strings are compared character by character, we don't need to do the
split and cast to int, we know that realistically a maximum of 4
characters (the first 4 numbers) are going to be compared in most cases.
* xenial doesn't ship many dependencies, so make them all optional
since we don't guarantee that everything will work
* cmake/{5,6}: needs stdlib.h for EXIT_SUCCESS on GCC 5
* common/222: needs C++11, and GCC 5 doesn't understand `auto`
correctly unless we explicitly enable it.
* frameworks/1 boost: xenial doesn't ship boost_python3, so make it
properly optional
* frameworks/6 gettext: gettext can be installed without xgettext,
which doesn't cause the project to fail, but the installed files
list is different which causes the test to fail.
* frameworks/7 gnome: gobject-introspection can't be enabled because
the sanitizer unit test detects leaks in glib and fails
Scalapack uses a library stack that can be challenging to manage.
Not least of all since many Scalapacks ship with broken / incomplete
pkg-config files and CMake FindScalapack.cmake
This resolves those issues for typical Scalapack setups including:
* Linux: Intel MKL or OpenMPI + Netlib
* MacOS: Intel MKL or OpenMPI + Netlib
* Windows: Intel MKL (OpenMPI not available on Windows)
Fortran: check for undeclared variables by forcing implicit none everywhere
C/C++: check for unused parameters and return types
removed unused variables from test cases
ci: do missing return and unused arg check with Github Actions
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Meson is not warning if you join paths with / but you are requesting a
version older than 0.49.0; fix this before adding more features to the
division operator.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These don't work and no one has fixed them. When I've tried to
download dmd for windows I can't get a valid installer from their
website. Let's at least turn the CI green.
This doesn't touch everything as it's just based on the python3 module
tests, ported to the python module. It's still better than the one very
basic test in the unit test module.
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.
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 compiler detector in detect_system_compiler(), rather than trying to
guess based on what it is the PATH (which could utterly fail e.g when CC env
var is set)
Note that this detection is only used by platform_fix_name() to interpret
installed_files.txt
This has the adventage that "meson --help" shows a list of all commands,
making them discoverable. This also reduce the manual parsing of
arguments to the strict minimum needed for backward compatibility.
As per commit 2340fd3, unexpected installed files are not reported anymore when
using compilers other than 'cl', this regression was introduced in the attempt
of not reporting extra .pdb files, but actually caused any non extra .pdb file
in other compilers to be ignored.
Fix boolean test, by reporting any extra file a part '.pdb' ones under non 'cl'
compiler, while anyone under 'cl'.
This is a simple test case, checking for installed_files.txt, which just
makes sure the syntax is accepted.
Manual tests confirmed the permissions were set correctly.
A follow up commit adds a unit test based on this directory.
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
I sincerely hope sufficient amounts of goats have now been sacrificed
at the altar of Debian Locales so things will actually work and I
can get to sleep.
Enable 'test cases/frameworks/10 gtk-doc' if gtkdoc version is 1.26 or
later.
Old versions of gtkdoc-scan also output the version to stdout rather than
stderr, so be sure to handle that...
Dylan Baker