Automatically colorize the text when printing the AnsiDecorator, based
on the result of mlog.colorize_console(). This is how AnsiDecorator
is used most of the time anyway.
* depenencies/llvm: Handle llvm-config --shared-mode failing
Fixes: #7371Fixes: #7878
* test cases/llvm: Refactor to use test.json
Instead of trying to cover everything internally
Split out tests (and parts of tests) which require a native compiler
from the 'common' suite to a new suite called 'native', so we can
selectively avoid running those tests when only a cross-compiler is
available.
Also move test '211 cmake module' to 'cmake' suite, since it appears
that the way we use cmake requires a native compiler.
This is useful for automatically generated docs (doxygen, hotdoc)
with a lot of generated files that may differ with different
versions of the generator.
* Add boost_root support to properties files
This commit implements `boost_root`, `boost_includedir`, and
`boost_librarydir` variable support to native and cross properties
files. The search order is currently environment variables, then
these variables, and finally a platform-dependent search.
* Add preliminary boost_root / boost_includedir tests
Each test contains a fake "version.hpp", as that's how boost detection is
currently being done. We look for this file relative to the root directory,
which probably shouldn't be allowed (it previously was for BOOST_LIBRARYDIR
but not for BOOST_ROOT). It also cannot help with breakage detection in
libraries, however it looks like this wasn't getting tested beforehand.
I've given the two unique version numbers that shouldn't be present in any
stock version of boost (001 and 002).
* Add return type to detect_split_root
* Return empty list when nothing found in BOOST_ROOT, rather than None
* Update boost_root tests
* Create nativefile.ini based on location of run_project_tests.py
* Add fake libraries to ensure boost_librarydir is being used
* Require all search paths for boost to be absolute
* Redo boost search ordering
To better match things like pkg-config, we now look through native/cross files,
then environment variables, then system locations for boost installations.
Path detection does not fall back from one method to the next for properties or
environment variables--if boost_root, boost_librarydir, or boost_includedir is
specified, they must be sufficient to find boost. Likewise for BOOST_ROOT and
friends. pkg-config detection is still optional falling back to system-wide
detection, for Conan.
(Also, fix a typo in test 33's nativefile)
* Correct return type for detect_roots
* Correct boost dependency search order in documentation
* Print debug information for boost library finding, to resolve CI issues
* Handle native/cross file templates in a more consistent way
All tests can now create a `nativefile.ini.in` if they need to use some
parameter that the testing framework knows about but they can't.
* Pass str--rather than PosixPath--to os.path.exists, for Python35
* Look for boost minor versions, rather than boost patch versions in test cases
* Drop fake dylib versions of boost_regex
* Prefer get_env_var to use of os.environ
* Correct error reporting for relative BOOST_ROOT paths
* Bump version this appears in. Also, change "properties file" to "machine file" as that appears to be the more common language.
on some systems, tests may take over an hour to run--only to find
you might have used an unintended Meson version (e.g. release instead
of dev). This change prints the Meson version at the start of the
run_*tests*.py scripts.
Also, raise SystemExit(main()) is preferred in general over
sys.exit(main())
Unify present or absent test.json file cases in gather_tests
Make expected stdout mandatory in test.json for some test categories
Use a trivial TestCategory class rather than a tuple, to make it easier
to default category attributes
Unify present or absent test.json file cases in gather_tests
Make expected stdout mandatory in test.json for some test categories
Use a trivial TestCategory class rather than a tuple, to make it easier
to default category attributes
Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
Expected stdout lines must match lines from the actual stdout, in the
same order. Lines with match type 're' are regex matched.
v2:
Ignore comment lines in expected_stdout
v3:
Automatically adjust path separators for location in expected output
v4:
Put expected stdout in test.json, rather than a separate file
Currently, colourize_console is a constant, set at process
initialization.
To allow the actual stdout to be easily compared with the expected when
running tests, we want to allow colourization to be on for the test
driver, but not for the in-process configure done by run_configure,
which has stdout redirected from a tty to a pipe.
v2:
Cache _colorize_console per file object
v3:
Reset cache on setup_console()
Adds the `tools` section to `tests.json` to specify requirements
for the tools in the environment. All tests that fail at least
one tool requirements check are skipped.
I have an NVME drive, I really don't want to be thrashing it with
temporary files. It's also annoying to watch vscode thrash about with
files that are quickly created and deleted. I'd rather put them in /tmp,
so I've added a non-default option to do so.
This is needed when mixing D and C code, as it's possible to end up
witha combination of linkers and compilres such that C produces pdb
files but D does not.
This allows the harness to apply the version correctly, putting it in the right
place, dropping the right amount of numbers, etc.
pdb taking a version allows it to be more easily copied from the
shared_lib type.
Add coverage of a simple 'configure then build' sequence, to catch bugs
which occur with that.
Also, to simplify returning results from functions called by
_run_test(), allow it also throw TestResult objects, which run_test()
catches and returns.
Looking at 45c8557d, the idea behind this seems to be that a test could
conditionally indicate that the list of installed files should not be
validated by creating that file.
It's no longer used anywhere.
Also remove a lingering no-install-files file which isn't used since commit
c693bd9b.
Just add or alter attributes of the TestResult object, rather than many,
many invocations of the constructor with very similar arguments.
Define helper methods for TestResult to add the results of a step and
set the failure reason.
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.
Dylan Baker