Since 25df6e7d split the iteration over tests to start them from the
iteration to collect their results, the variable 'name' is only being
set in the first iteratiorn, so all tests are treated as being in the
last test category read (probably 'wasm') for skipppable() and in the
XML output.
Store the category name in the TestDef object
Use it in skippable()
Use it in classname attribute of XML test results
As a side-effect from #8885 `find_program()` returns now `Executable`
objects when `meson.override_find_program` is called with an
executable target. To resolve this conflict the missing methods
from `ExternalProgram` are added to `BuildTarget`.
This reverts commit 72365e6856.
This is a vanity project that no longer exists.
See discussion at #8890, which still requires further thought but we can
at least start off by removing something clearly invalid.
Tests that we find something sensible for intl, capable of producing
binaries using gettext() to translate stuff.
No more need to manually check headers and *maybe* include the intl
library, which we were doing before; the new dependency actually
simplifies the existing test, and should simplify users' build files
too...
Checking how to aquire the *gettext family of symbols portably is
annoyingly complex, and may come from the libc, or standalone.
builtin dependency:
This detects if libintl is unneeded, because the *gettext family of
symbols is available in the libc.
system dependency:
This detects if libintl is installed as separate software, linkable via
-lintl; unfortunately, GNU gettext does not ship pkg-config files for
it.
Fixes#3929
Since we pass a method: 'foo' to every one of these
config-tool/pkg-config dependencies, we do not ever need to check which
type_name it has; change these to asserts instead.
In the process, we discover a bug! We kept checking for type
'configtool' instead of 'config-tool', so these tests all
short-circuited and checked nothing. Once moved to an assert, the
asserts failed.
Add a new lookup for a known system dependency and make it assert that
too.
mesonbuild.dependencies.__init__ exposes configtool, pkgconfig, cmake
and more in __init__.py, so there's no reason we should be tying
SystemDependency to the internal organization implementation of the
subpackage!
In the 2nd previous commit it took quite some effort to figure out that
the python module "does not exist" because of import errors while
refactoring something completely different.
For dependencies that on some systems are built into libc etc. and don't
need to be separately linked. This is distinct from "system"
dependencies which add linker args.
Dylan Baker
Jon Turney
Justin Handville
Daniel Mensinger
Orta Therox
Xavier Claessens
Eli Schwartz